Feedback from Microsoft on ARIA from a web developer perspective

Hello PF working group members,

I am the Microsoft rep to the WCAG working group.  Along with several others from Microsoft, I've been reviewing ARIA, and have some questions and concerns from the perspective of the web developer.

Issue 1:  Differences between the HTML and XHTML implementations

We think that HTML, rather than XHTML, will be the mainstream case for a long time.  The XHTML solution is much cleaner than the HTML solution.  We understand that there are significant limitations in HTML, and that this is an effort to work around them, which is difficult problem.

We'd like to understand what other ideas were considered for HTML, and why this one was chosen.

It will be confusing to developers to have different implementations for HTML and XHTML.  Many web developers don't really understand the difference, and many web pages don't have the right declarations.  Is there anything we can do to make these more similar to each other, so that developers don't have to understand what doctype they're using, in addition to understanding script and accessibility?


Issue 2:  Conflicts between ARIA markup and native HTML semantics
We should be encouraging web developers to use native HTML elements when they exist.  Is it good to allow mapping arbitrary elements to roles that exist in native elements?  For example, is it good to be able to mark a span as a link, when there is already a native link?  While it does work for AT that uses Accessibility APIs, it won't work for those that rely on HTML semantics. It can also break other technologies, not related to accessibility, that rely on HTML semantics. It is true that there are some UI constructs that are not easily expressible in native HTML. Slider is an example of such a control. It does make sense to have a way to mark these up with ARIA.  However, I worry that allowing the markup of arbitrary elements with the roles of existing native elements will encourage sloppy coding.

We at Microsoft have some experience with our Drawn User Interface technology that might be interesting to consider here.  Like DHTML + ARIA, DUI allows developers to create their own User Interface widgets, and then manually map their UI to appropriate roles and states.  We have found that developers and designers frequently do this mapping poorly.  This is true even within Microsoft, where the technology was invented, and where we have highly skilled development teams, who are trying to do the right thing.  With less motivated developers, the mapping is often not done at all, resulting in accessibility problems.

How can we make it easier to get correct, consistent accessibility properties across multiple web sites, where the skill level and motivation level of the site owners varies greatly?

Has the group considered defining roles only for those UI elements that are not available natively in HTML?

Issue 3:  Quality and Maintainability of web site code
Both the HTML and XHTML approaches add the access info directly to each element.  That gives many opportunities for errors.  Even assuming that the devs chose the right values in the first place, multiple locations mean multiple places for coding errors to occur, and multiple places to update when the site changes.

We feel that it would an undue burden on the majority of authors to include ARIA information in all web pages, we would propose a mechanism enabling separating the Accessibility information out in a manner where it could be tackled once by accessibility experts.  This is particularly of concern in large sites, but also for smaller authors who are using cut and paste methods to implement their UI widgets.

This would help with issue 3, and might be able to be implemented in such a way that it would help with issue 1.

Possible approaches could use a CSS like mechanism, the <link> tag in HTML or adding the ARIA information from script.  .  Since ARIA is intended to add accessibility information to DHTML, assuming the presence of script seems reasonable.


Thank you for your attention,

Cynthia Shelly
Senior Program Manager, Windows Live Accessibility