- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 23 Mar 2009 14:28:20 +0200
- To: John Foliot - WATS.ca <foliot@wats.ca>
- Cc: <joshue.oconnor@ncbi.ie>, <mjs@apple.com>, "'Charles McCathieNevile'" <chaals@opera.com>, "'Wai-Ig'" <w3c-wai-ig@w3.org>, <wai-xtech@w3.org>, "'HTMLWG'" <public-html@w3.org>, "'WebAIM Discussion List'" <webaim-forum@list.webaim.org>, "'Gawds_Discuss'" <gawds_discuss@yahoogroups.com>
On Mar 23, 2009, at 08:15, John Foliot - WATS.ca wrote: > Joshue O Connor wrote: >> >> Yes, all the more reason to ensure that the API is suitable / >> before/ it >> leaves the stable so we are not facing a situation where we need to >> retrofit the API for accessibility. >> >> Josh >> > > In light of the recent change from 'should' to 'must' (RFC 2119), if > retrofitting the API is out of the question, then what exactly is > the plan > to ensure conformance? The HTML5 WG and WHAT WG have gone to great > pains to > ensure that pages will conform, so please all, how or what is going > to be > done to address this issue? > > The spec says 'must', thus you must. If you do not, then what > happens? > Logic can only lead to one conclusion, the page is non-conformant. > What is > the price for non-conformance? (Henri, your thoughts?) I'm not sure why this question is addressed to me. Is it because I develop an HTML5 validator? Or because I've mentioned that the existing low-level accessibility API available to JavaScript is creating a DOM tree of <div>s and putting ARIA attributes on the nodes? Also, it isn't quite clear what you mean when you say "conformance" here. I assume you mean that what is exposed to an accessibility API is consistent with the visualization painted on <canvas>. Checking that a program uses an accessibility API in a way that is consistent with its use of an immediate-mode 2D drawing API is not a computable problem. So if the question was meant to me with my validator developer hat on, I think the issue is outside the realm of things that a validator computes. As Maciej pointed out, other programming environments that provide a 2D drawing API and an accessibility API do not try to enforce their consistent use. It seems to me that cost of failing to program to an accessibility API in a way that exposes information consistently to what is painted visually using an immediate mode 2D drawing API is the cost of the application being inaccessible by people who can't use the visual output and would rely on the exposure of information through the accessibility API; see http://lists.w3.org/Archives/Public/public-html/2009Mar/0548.html P.S. I haven't discussed the use of a <canvas> subtree of <div>s with ARIA attributes with developers using <canvas>, so I don't know if that approach actually would fit e.g. the Bespin case. Having a tree with <div>s with ARIA attributes is to accessibility what SVG is to 2D graphics, so the API models of <canvas> and an ARIA tree would be different. I'm not sure if it is even feasible to expose an even lower level accessibility API to Web content in a browser considering that an even lower-level API would entail an accessibility API client such as a screen reader calling into untrusted code (Web author-supplied JS) which could expose software stability issues. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Monday, 23 March 2009 12:29:07 UTC