- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 26 Mar 2008 14:46:03 +0200
- To: Lisa Seeman <lisa@ubaccess.com>
- Cc: public-pfwg-comments@w3.org
On Mar 26, 2008, at 12:39, Lisa Seeman wrote: > Landmark roles such as secondary are from the XHTML roles They are in the ARIA spec, though. While the XHTML Role Attribute Module spec is not relevant to HTML 5, people have expressed expectations of integrating ARIA with HTML 5. I'm interested in how ARIA could be integrated with HTML 5. I talked with Hixie about this, and as it stands ARIA isn't ready for wholesale inclusion in HTML 5. > I think the processing requirements in this case are simple - enable > adoption to your user base needs. That's totally vague. That's not a processing requirement that leads to interoperable implementations. > It is not our thoughts to dictate how your users need content, just > to > enable you to adapt content for them. Telling implementors to figure something out is not good enough. > for example , many browsers may ignore secondary > > If this is a screen reader, maybe secondary content should be read > after > main content "May" and "maybe" don't sound convincing. As an author, how do I figure out whether using role=secondary makes sense? Writing semantics into a Web page / Web applications has a cost. Even when the cost isn't monetary, there's an opportunity cost. Telling people to make an effort with a cost without any concrete indication about what the effort is supposed to accomplish is unkind to the people who are expected to make an effort and if you want them to trust expert advice on accessibility. If they figure out that you are asking them to spend time over practically nothing, they may ignore you even when what you are requesting would improve accessibility. > This should also explain email "Spec is devoid of processing > requirements > for states and properties" It explains why the spec is the way it is, but it does not solve the problem. If the ARIA spec fails to spell out implementable, realistic and detailed processing requirements, it isn't really the document specifying ARIA as far as implementors are concerned. Instead, the developer.mozilla.org wiki and the Gecko source code at mxr.mozilla.org become de facto normative (until another implementation leapfrogs Firefox on a particular ARIA feature at which point implementors will have to reverse engineer that implementation for that feature). That's like going back to the bad old days of HTML 4. You can't implement an HTML browser that works with Web content by reading UA requirements from the HTML 4.01 spec. Instead, you needed to reverse engineer other browsers until HTML5 came along. Failing to put detailed processing requirements in the WAI-ARIA spec is like inviting someone else to write an ARIA5 eventually. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Wednesday, 26 March 2008 12:46:50 UTC