L. David Baron wrote:
>
> (I'm not happy about this spec; for a good description of why, see
> http://lists.w3.org/Archives/Public/public-html-admin/2014Aug/0028.html .
> I'm also under the impression
Your "impression" is wrong, and even if Firefox were to drop its
implementation of @longdesc today, there are enough other implementations to
meet the W3C requirement of 2 independent instances, so rather than making
assumptions, get the facts. Removing existing support from Firefox however
would be foolish, and hardly in keeping with the Mozilla Foundations mission
statement:
"At Mozilla, we're a global community of technologists, thinkers and
builders working together to keep the Internet alive and accessible, so
people worldwide can be informed contributors and creators of the Web. We
believe this act of human collaboration across an open platform is essential
to individual growth and our collective future."
(Q: what part of openness = rejecting an attribute that many still want to
see retained? That seems very "closed" to me...)
> that they're using Mozilla's
> "implementation" of it as support for the spec, which is rather
> galling considering that a big piece of what led to that
> implementation was an online harrassment campaign against a Mozilla
> UX designer to get the feature accepted.
Using Mozilla's up-voting of bugs is only "harassment" when you disagree
with the bug. There were many sincere and intelligent people and
organizations that supported the reinstatement of the attribute, and there
remain some today saddened that the final result appeared half-hearted.
None-the-less, Firefox now provides support for the majority of the primary
target audience (screen reader users), while partially ignoring other
user-groups that might also benefit from the longer text descriptions
provided via @longdesc. (Does it come as such a surprise that even the
accessibility community will accept am 80/20 solution sometimes?)
That support BTW will also allow Firefox to continue to claim a high level
of HTML5 conformance (https://html5test.com/results/desktop.html), certainly
higher/better than Safari, currently the only mainstream desktop browser to
*NOT* support @longdesc (and with VoiceOver, currently the only mainstream
screen-reader to not support @longdesc).
Finally, I'll even go so far as to suggest that if you improved your support
for @longdesc, it might be yet another differentiator for choosing Firefox,
an issue I know your Robert O'Callahan is quite concerned about:
http://robert.ocallahan.org/2014/08/choose-firefox-now-or-later-you-wont.htm
l
> I'm not sure how much it's
> worth fighting it at this point, although probably a first step in
> that fight would be to remove our implementation.)
Meanwhile, Jonas Sicking wrote:
>
> I tried winning this fight, but found it not worth my time. The problem
> was that even after getting this feature removed from W3C specs once,
Ian Hickson's ham-fisted approach to this attribute, and accessibility in
general, was never seen as 'welcome' or appreciated by many inside of the
W3C, and his antics continue to frustrate many, even today. For the record,
@longdesc was never "removed" from a W3C spec, it just took longer to get it
added to the W3C HTML5 spec (and still remains today a valid HTML4 / XHMTL 1
attribute).
The cool kids might continue to think that the WHAT WG is still all that,
but outside of the rarified air of that echo chamber, the majority of the
world still looks to the W3C as the definitive source, in part because their
process is both open and fair, and not controlled by a single entity.
> the proponents of it simply harassed people again and again until it
> got added back to the HTML spec. I guess it got removed again and yet
> again they were able to get it back.
Your recollection of the history is incorrect - and please, take it from
somebody sitting ring-side (when I wasn't actually in the ring).
@Longdesc was finally added to W3C's HTML5 because, despite multiple claims
that is wasn't whatever opponents thought it should be, no-one was ever able
to address all of the extremely complete and well-documented use-cases with
any other robust solution - including Apple. Having a collective of sighted
engineers telling the non-sighted community that they don't need a feature
because those same sighted engineers had a hard time 'getting it' is, was,
and remains unacceptable.
>
> The W3C process is clearly not robust enough that we can prevent this
> type of stuff form making it into a spec.
That of course is a matter of perspective and opinion. It could also be
argued that the W3C Process saved a valuable accessibility attribute from
being discarded by a group of engineers who failed to grasp the need for the
attribute in the first place, or were swayed by the cult-of-personality of
Hixie, who didn't like @longdesc, so being "King of the World" he tossed it
aside.
W3C Process ensured that the pros and cons of retaining versus obsoleting
the attribute were thoroughly and completely discussed and examined in a
public and open way, and while some did not want to see it remain, the
prevailing view was to retain it. It is also worth pointing out that the
W3C's open process even allowed Apple to file a Formal Objection against the
decision (think you could do something like that at WHAT WG?) That very much
feels like "Transparent community-based processes (that) promote
participation, accountability and trust." (source:
https://www.mozilla.org/en-US/about/manifesto/)
I'm not sure about you, but I generally choose democracy over autocracy
roughly 100% of the time.
> So I agree that the best tool
> we have at our disposal is to simply refuse to implement, or in this
> case remove our, as I understand it largely useless, implementation.
Then, like your colleague David, your understanding is incomplete.
Could Firefox's implementation be improved? Absolutely. But, when paired
with screen readers such as JAWs and NVDA, can it solve a real problem for a
real user? Yes, yes it can.
"The Internet must enrich the lives of individual human beings."
https://www.mozilla.org/en-US/about/manifesto/
Does @longdesc aid non-sighted users who are using eBooks from Pearson
publishing achieve their education goals? Does it allow academic intuitions
in the U.S. to better meet their Section 504 and Section 508 obligations?
Why yes, it does that too.
"The effectiveness of the Internet as a public resource depends upon
interoperability (protocols, data formats, content)... The Internet is an
integral part of modern life - a key component in education, communication,
collaboration, business, entertainment and society as a whole."
https://www.mozilla.org/en-US/about/manifesto/
(Marco Zehe wrote: "Besides: It does give us a competitive advantage over
other browsers in the academic space and whereever other space longdesc may
be used, or start being used once it is officially sanctioned by the W3C.
Remember in accessibility world, the W3C word weighs much more than some on
this list might think." ...so if you don't want to believe me, believe
Marco)
Does @longdesc add to the current crop of shiny CSS web-candy and
"responsive design" wonderment that seems to so-impress the Bay Area 'it'
crowd? Nope, sorry, it doesn't do that.
Just because you and your circle of colleagues don't use a feature doesn't
make it useless - Q:how often do YOU *navigate* a web site using HTML5's
landmark elements? Does that make <nav> and <aside> useless? (I didn't think
so...)
> It's sad that people are spending time on features like this when there
> are far bigger accessibility problems with the web platform. The fact
> that native platforms, especially iOS, has caught up and surpassed the
> web when it comes to delivering accessibility "built in by default" is
> a sad state of affairs.
The day you can point to a "native" solution that solves the problem that
@longdesc solves *today*, and is fully supported in all browsers (so no, SVG
isn't quite the solution yet), then I will agree with you. However today is
not that day, and so in the absence of a better solution, we have @longdesc.
Not a single person will say that @longdesc is perfect, but no better
solution has been brought forward, so flawed is better than nothing.
It's sad as well that some engineers keep wanting to be right on this issue
(I'm looking directly at you David Baron and Anne van Kesteren) that they
continue to bleat on about this, when the issue has been, for the most part,
resolved at the W3C. It certainly strikes me as sore (and slightly immature)
losers - but then, that's just me.
If Mozilla wants to move backward in its accessibility support, that is of
course your business decision to make, but as has previously been pointed
out, what kind of message would that be sending? "To hell with the blind
people"? Consider the optics carefully.
> The fact that the web was based on a semantic
> language like HTML was always supposed to deliver a strong
> accessibility story.
Yup, and adding semantic elements such as the aforementioned landmark
elements was a huge move in the right direction.
But the "semantics" of an infographic is that a sighted person crams a bunch
of data into a "picture" and posts in on a web page using the barely
semantic <img> element. To ensure that picture is accessible to non-sighted
users, you need to provide a text equivalent of that picture *somewhere*,
and naively thinking that designers will include that text on the same page
as the infographic flies in the face of any design aesthetic I've ever
encountered over the close-to 20 years I've been on the web, and I challenge
anyone to show me a production website with an infographic today that does
that. Solve *that* problem, and then you can retire @longdesc - but not
before. This was the argument that won the debate at the W3C.
> Sadly it has for authors become easier to deliver beautiful websites if
> they simply create an endless pile of <div>s than if they actually use
> semantic markup.
...and right there, you've summed it up. "Beauty" for non-sighted users is
information in a format they can use, not pictures, nor snazzy CSS
transforms and animations, and not jQuery scripted <divs> that are the 21st
century equivalent to dancing mailboxes and animated java applets, and
without the means to deliver the functional equivalent of a complex image,
the web is less beautiful for those non-sighted users.
I would think that with Mozilla's commitment to the end user, that message
wouldn't be so hard to understand.
JF
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
