- From: John Foliot <foliot@wats.ca>
- Date: Sun, 29 Jul 2007 00:10:00 -0700
- To: "'Lachlan Hunt'" <lachlan.hunt@lachy.id.au>, <public-html@w3.org>, <wai-xtech@w3.org>
Lachlan Hunt wrote: > > As I see it, the UA is still going to render the whole page. If a > user configures their UA to not download videos by default, then it > doesn't have to. The user can then read the page, and when they > reach the link to the alternative content, they can download it. So in other words, if you are sighted then you "automatically" get the video, but if for some reason you are non-sighted, or cannot access the video for some other reason, then take the second-rate alternative and read through the page to find the link. Providing an alternative 'within' the embedded object (video) provides 'equal' delivery of content. This is *exactly* the type of response/attitude I find troubling. It is a second-class solution that need not exist, and is no different then providing the wheelchair accessible door at the rear of the building. > >> It would allow testing tools to check that there is an alternative >> associated with the video. This is important for the purpose of >> verifying conformance to site-wide or organizational policies, WCAG >> specifications, etc. > > 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. However, the current direction of the Draft WCAG2 asks (demands?) that features be testable, and preferably mechanically, so you are in some ways incorrect. While this is no guarantee that the results actually improve accessibility, it none-the-less ensures that some effort is put into the production of the web content. While there is no argument that mechanical testing does not 'automatically' ensures accessibility, this is not a reason to _NOT_ provide this type of feature, especially given the direction of the next generation WCAG. > >> The explicit association would also open up the possibility of >> special treatment, in the user interface, of links to alternative >> content, such as aural highlighting or access keys provided by the >> user agent, without leaving these to be implemented by the content >> author as an implicit association would do. > > 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. Again with the research! Please point me to the research that proves that <canvas> is REQUIRED, WANTED OR NEEDED by *users* - not developers, *USERS!*. Until the HTML-WG can provide this type of conclusive evidence, then when the accessibility community recommends that you consider something, it should be presumed that it is based on the same kind of presumptions that advocate for new features like <canvas>. > > 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. You seem to forget that UA's work in conjunction with AT. YouTube is not a great example, it simply remains inaccessible to a significant population - period. However, YouTube is in the "entertainment" category, so it is not necessarily a good example. In the field of academia, videos are increasingly becoming a significant teaching tool, and in this area providing appropriate alternatives is not just a good idea, it's the law. Allowing the next generation of markup language to provide this implicit association is not that different than providing the ALT attribute for images. >> This is inadequate for the reasons outlined above. > > Only one of the reasons you gave was a possibility, and even that's > not yet conclusive. Therefore you can't yet claim that implicit > association is inadequate. Likewise, I can't conclusively claim that > it is, but that would still be my hypothesis. However, it is the hypothesis of many in the accessibility community that non-implicit associations would likely be inadequate. Why does your hypothesis trump ours? On one hand you demand *proof*, but in the next breath speak of hypothesis. Why does this feel like a double standard to me? > > 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. And you see, this is exactly the problem. Without a large pool of *proof* you presume that any existing solutions are ineffective, and that any recommendations from our community are "over-thought". It's not always that the solutions themselves are ineffective, but rather that awareness and implementation is slow to emerge. Once again, accessibility can't be judged by cowpaths: it's simply not the right metric to use. There are a number of emerging solutions that are looking to improve the situation for "captioned" videos. One might be ClickTV (www.click.tv - sadly temporarily off line), or solutions such as DocSoft (www.docsoft.com). They aren't perfect, but they are trying to provide the means to improve. Given better solutions, including improvements in mark-up code, will encourage companies such as these to "take the ball and run with it". Sometimes we just need to wait until the "Proof is in the pudding" - you need to make the pudding first. JF
Received on Sunday, 29 July 2007 07:11:02 UTC