[html4all] from hixies log - Fire, a two-hour weekend, accessibility, and other rants

[John Foliot]

This isn't just my opinion. It was clear at the festival that the sizeable
deaf community present there was fully enjoying the music. The presence of
sign language interpreters made them feel part of the event, and conveyed
everything that they wanted conveyed. 

Could it be then that images on sites like Fickr might be useful (enjoyed)
by the blind or low-vision? (Insist on alt text, don't make it optional)
That new elements like <video> *must* be constructed so that the non-seeing
can experience a different but equally enjoyable experience?

    "Content may be provided inside the video
<http://www.whatwg.org/specs/web-apps/current-work/#video1>  element so that
older Web browsers, which do not support video
<http://www.whatwg.org/specs/web-apps/current-work/#video1> , can display
text to the user informing them of how to access the video contents. User
agents should not show this fallback content to the user."
[http://www.whatwg.org/specs/web-apps/current-work/#video]

Wrong!!! Content *MUST* (not may) be provided inside the video
<http://www.whatwg.org/specs/web-apps/current-work/#video1>  element so that
older Web browsers, which do not support video
<http://www.whatwg.org/specs/web-apps/current-work/#video1> , can display
text to the user informing them of how to access the video contents. 

    "User agents should not show this fallback content to the user" 
(Why not? How does this help anyone?)  Just because my user-agent does not
support a visualization of video content should in no way restrict the user
access to any other aspect of that object?  Those deaf people couldn't hear
the music, but by your own admission enjoyed the show none-the-less.  Where
is this type of consideration in the spec?  *This* is what drives the
frustration.

Meanwhile, the hearing patrons enjoyed the music and the sign language - I
heard comments from several people to the effect that the sign language
interpreters were effectively an intrinsic part of the act. (To the point
where even people who didn't necessarily understand sign language had
opinions on which interpreter was better.)

Contrast this against suggestions to make alternative text optional, and
considering deprecating LONGDESC, and arguing for*not*  (or at least not
insisting on) providing fallback for various visual effects.  You say and
believe one thing, but HTML5 advocates in the opposite direction.

It's interesting how the prevailing opinion of Web accessibility experts is
so far removed from the existing and successful accessibility practices in
the non-tech world.

The festival organizers had the ability to invite signers onto the stage,
and had the means to "broadcast" the signers to the crowd... sort of like a
human visual LONGDESC <smile>:  most festivals of course don't provide this
(probably less than 0.06%...), but there is nothing within the "Festival
Handbook" that *removes* the ability to provide this type of accommodation.

What is being lost is the fact that there are 2 aspects to be considered:
Universal Design and Accommodation.  All of the prevailing suggestions
coming forth from the HTML5 WG are driven by the Universal Design concept -
which is not a bad thing - but when it comes to Accommodation,  lack of
"data" is producing bad decisions: headers/id, LONGDESC, @alt(optional), <i>
vs <em>, and on and on... the proposals remove the ability to fully
accommodate specific needs; a different aspect of accessibility that seems
to be left out of the discussion.

I hope you enjoyed Burning Man, and look forward to continued work on HTML5

JF

 

 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20070905/7ef24316/attachment.html