- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Sat, 28 Jul 2007 13:47:20 +0100
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- CC: public-html@w3.org, wai-xtech@w3.org
Lachlan Hunt wrote: > I don't understand that reason. In particular, "while presenting only a > single link to the user interface" doesn't make sense. Where and how > are you imagining the UA to present this single link? In place of the video, if the user has chosen to so configure the UA (either manually, or in conjunction with a combined CC/PP and ACCLIP http://www.imsglobal.org/accessibility/#acclip profile). > There is no requirement for all accessibility features to be testable > using automated accessibility testing. Such a requirement would only > place arbitrary restrictions upon the development of accessibility > features, limited by the abilities of testing tools. Accessibility > features should be evaluated according to how well they benefit users, > not how easily a tool can test for it. Agreed, but user agents need to, imho, also be able to make sense of the markup/content associations, so they can let the end user know that they're not missing out on any content just because they can't render the video, for instance. > Possibly, but that would need research to determine things like whether > users actually want or need that feature, whether or not they would > really use it if it were available, and whether UAs, especially > assistive technology, could or would implement it. And, going back to the usual argument, we'd need user research to determine if NOT providing the suggested association would harm or inconvenience the users. Also, I find it quaint that you have the "whether UAs could or would implement it" there. Is this sort of rigorous research also applied to all the other decisions that have been made up to now (cowpaths and all) with regards to HTML5? > BTW, there was a suggestion for <a rel="longdesc"> a while ago, which, > when used within <figure> and <legend>, is a possible solution. I'd love to see a more direct relationship, maybe along the lines of how <label for="#IDREF"> works for form element labels. > No, the user is the whole point. If it can be conclusively shown that > the user is somehow disadvantaged because their UA doesn't provide some > special functionality, then we can look at addressing those problems for > the user. But simply assuming that the UA needs to do something special > and then jumping to the conclusion that we need to provide for that > doesn't help. And vice-versa. Also, I believe that the core idea here of user agents doing "something special" is firmly based on how they currently already handle <img alt="..."> (where screen readers, for instance, "do something special" in terms of reading out the ALT, rather than simply saying "here's some image, full stop", and based on the way that <object></object> fallback content is rendered in situations where the UA is unable - either through missing plugin/handler or through user preference - to render the object itself). > I'd like to see some user testing of this issue, and some documentation > of existing video sites and their accessibility features. Are there any > existing video sites that provide textual alternatives for videos? If > so, we can look at how they do it and, through user testing, evaluate > how successful their approach is. Just wondering (as usual again) why, if we're working on a new set of language building blocks, we need to look at current practices that use the limited vocabulary available today...whatever sites currently do is obviously related to how HTML4/XHTML1.x handles video and such. Why should that inform how this new and improved language should handle it as well? But yeh, let's go along with that... P -- Patrick H. Lauke ______________________________________________________________ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com ______________________________________________________________ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ ______________________________________________________________ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ ______________________________________________________________
Received on Saturday, 28 July 2007 12:47:24 UTC