- From: John Foliot - Stanford Online Accessibility Program <jfoliot@stanford.edu>
- Date: Tue, 26 Jun 2007 12:57:55 -0700
- To: "'Henri Sivonen'" <hsivonen@iki.fi>
- Cc: "'HTML WG'" <public-html@w3.org>, <wai-xtech@w3.org>, <w3c-wai-ig@w3.org>
Henri Sivonen wrote: > > I guess the new HTML5 features need a lot more marketing as > accessibility features. It is kind of sad that the accessibility > interest part of the blogosphere has focused on the HTML 5 draft not > having certain attributes (yet) and not noticing how many new > features have accessibility-friendly semantics without needing > annotations specifically for accessibility. Henri, here you make a superb point. What the accessibility community has seen (and heard) so far has been essentially confrontational responses from the working group. I am thinking of debates such as using @class to extend semantic meaning (and the whole <span class="copyright">Nothing to do with copyright, but needs to be fine print</span>) debate, the folly of <b> and <i> (and what exactly does italicizing the text mean?) and a protracted even hostile discussion surrounding the need to preserve headers and ids for tables (as but 3 examples that spring to mind). We've not heard one word of the accessibility friendly features being proposed. Perhaps some concrete examples would be apropos? > > However, for the custom widget case, ultimately native elements for > all available roles and XBL for custom widgets would be a more > elegant long-term solution. I do realize, though, that the main > advantage of role='' over XBL is that role='' doesn't require the > deployed installed base of browsers to participate as a whole in > order for expert authors to target the browsers that do participate. And this argument (and variants of it) have been coming from the accessibility folk for some time. Henri, go back and research the archives, and see how often it's been countered with "... The majority will never do it..." type responses. It is one of the key threads in the Pave the Cowpaths discussion. Not everyone can be an expert in everything, but for those who do specialize in ensuring accessible content ("expert authors"), the tools must exist. Too often, what we've heard instead is that there needs to be a large enough use-case, or that there are currently not enough viable examples in the wild, or what-ever. All of these arguments have essentially negated the role (and importance) of said 'expert authors', and their needs. Our needs may be edge-case, but they are real none-the-less. In another response, you wrote: > I still find it curious how accessibility experts have faith in > authoring software gaining all manner of features while at the same > time assuming explicitly or implicitly that AT will be more or less > frozen to its current state. Authoring software can be as 'complex' as notepad, and if that is the only tool I can have to improve accessibility as an 'expert author', then that is the tool I will use. Will it be time-consuming? Yes. Is this efficient? No. Does it improve the content for our edge-case constituents? Yes, and that is why I will do it. Do I wish that next-gen authoring tools would/could support these capacities? Of course, but then again, the WG also are hoping that these tools will support other new ideas like <canvas> and <progressbar>. But as you note later (below), attributes such as @role already have some UA/AT support today, so there is a business case to add this capacity to authoring tools today as well. The other thing to keep in mind is that the rate of adoption of some Adaptive Technology is much slower within the user community that requires it, due to the (sadly) general fact that this constituency is often living much closer to the poverty level, coupled with the fact that Adaptive Technology can be quite expensive. Tools such as JAWS can cost in excess of $1,000 USD (https://sales.freedomscientific.com/category.aspx?categoryID=11) - so while it may not be "frozen", next-gen adoption of Adaptive Technology can be severely arrested - even though JAWS is at version 8, I know many users who are still using JAWS 6 today. And while there are some emerging open-source AT tools today, the reality is that few software developers are interested in this arena, as the user-base is small(er). This is but another reason to continue to support what we already have today, not remove it. > > I agree that HTML5 will need to have role='' and headers='' as short- > term measures and as overrides for handling corner cases when easier- > to-author methods fail. It is rather pointless to make non-conforming > something that Firefox and JAWS already support. Am I hearing a fundamental shift in attitude? If yes, then hurray! > > However, I think they should be presented as short-term measures and > as overrides when other ways fail instead of being presented as > primary way of making HTML accessible on the long term. And the HTML > WG should seriously consider the long term. Which perhaps it has been, however I think that they lost sight of the short term, which has been (I suspect) the cause of some consternation in the accessibility community. > > That is, I still think that <progress> is the curb-cut installed as > part of the routine paving process in the front of the building and > role='wairole:progressbar' is the retrofitted ramp leading to a side > door. A retrofitted ramp is better than no ramp, but surely we should > make something better for new construction. ....and if this is the "new" way forward, then I for one am ecstatic. Henri, the accessibility community have fought hard for "enhancements" such as @role, even if they require expert-author status to implement (our community does a lot of train the developer outreach too); however this is better than nothing at all. What we were seeing (perceiving?) was a lot of this progress was going by the wayside. We need things like headers and id, and longdesc (!!), and "proper" ability to add semantic meaning (I am still very wary of @class, and it's misuse in "the wild" today), and @role for AJAXian on-screen widgets. If the working group can come up with more elegant solutions, that are easier to implement and truly delivers what we need (scope does not equal headers/id!), then we will cheer. But in the interim, we cannot afford to lose what we already have - a fear that earlier threads have planted within our community (and I am not the only one who has felt this way). In short, we should not need to argue for any accessibility construct that already exists - if there is a better way forward, then fine, but the "removal" of any the existing tools should not ever be debated: leave what we have until a better solution exists and is supported, even if it is difficult, or complex to do, or edge-case. I sense that this is also what your post is suggesting, and if that is the case, then we are on the same page. JF
Received on Wednesday, 27 June 2007 18:07:11 UTC