- From: Alan Chuter <achuter@technosite.es>
- Date: Thu, 20 Sep 2007 13:22:22 +0200
- To: "Mobile Web Accessibility Task Force" <public-bpwg-access@w3.org>
For those who missed the beginning this is about WCAG 1.0 checkpoint 11.4, "If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page." [1] and THEMATIC_CONSISTENCY "Ensure that content provided by accessing a URI yields a thematically coherent experience when accessed from different devices" [2]. Sorry this is a bit long-winded.... There is a fundamental difference between mobile-awareness and accessibility. With the former, it is assumed that we can detect the characteristics of the user's device while with the latter, neither the user's limitations nor the assistive technology are detected. This is the basis for design-for-all. If the content is accessible, the user will customise the rendering using assistive technology. Mobile Web BPs turn this around by encouraging customised content at the server end. Accessibility only requires a special version in very special cases (for example, an interactive 3D visual model of the solar system is very difficult to make accessible for someone who can't see it, so an alternative is needed). There are attempts to describe the user's special needs (a Dublin Core vocabulary) and to use that to provide customised or alternative content (like in online learning environments) but that is not the design-for-all strategy of WCAG. > when accessible content is requested, it is likely to have been > requested in the desktop context. Disabled users are just as likely to use mobiles. But they don't request accessible content, rather they expect to be able to access all content in equal conditions. What WCAG says is "if you can't make content accessible, provide an equivalent accessible version" but what it should say, but doesn't, is "only do so as a last resort" the checkpoint is too often used as an excuse to provide a text-only version, just assuming that the author knows in advance what the users needs are, which they never can know. To summarise, what I think this is about is that THEMATIC_CONSISTENCY is different to the WCAG checkpoint: * In the mobile context we know about the device, in design-for-all, we don't know about the user or the device. * Mobile-awareness encourages us to always provide a customised experience, WCAG only exceptionally. I think this is perhaps a red herring in the document that may just confuse people. [1] http://www.w3.org/TR/WCAG10-TECHS/#tech-alt-pages [2] http://www.w3.org/TR/mobile-bp/#THEMATIC_CONSISTENCY best regards, alan En Thu, 20 Sep 2007 11:31:00 +0200, Jo Rabin <jrabin@mtld.mobi> escribió: > > I think the discussion on THEMATIC_CONSISTENCY is at the heart of the > work that this TF addresses. In pointing out that the same URI can yield > different content depending on user context, I think it is clear that > this means not only a specific mobile version (or versions) but also an > 'accessible' version. > > So in response to the question "Do I really need to create a separate > mobile rendering", if the answer is "If you do that you will also have > an accessible rendering" that would be a powerful response. > > On the other hand, a difficulty with this approach is that we advocate > that people consider adjusting the content to meet the needs of mobile > users, which are typically distinct from the needs of desktop users. If > that is so then the mobile rendering, while possibly meeting the > technical demands of accessibility, might not address the point that > when accessible content is requested, it is likely to have been > requested in the desktop context. > > Jo > > > -- Alan Chuter Accessibility Consultant Technosite (Fundación ONCE) achuter@technosite.es www.technosite.es Tel. +34 91 121 03 35 Skype: achuter1 If you are unable to reply to this message because of spam filter, try my alternative address achuter.technosite@yahoo.com. Si no puede contestar a este mensaje por culpa del filtro de spam, intente con mi dirección alternativa achuter.technosite@yahoo.com.
Received on Thursday, 20 September 2007 11:23:55 UTC