Warning:
This wiki has been archived and is now read-only.

ChangeProposals/ARIAinHTML5-hixiecounter

From HTML WG Wiki

< ChangeProposals

Jump to: navigation, search

Objections to: HTML5 editors counter proposal to Issue 129

1 Objections to: HTML5 editors counter proposal to Issue 129

Contributors to this Response

Steve Faulkner
Rich Schwerdtfeger
Cynthia Shelly
Jon Gunderson
Sally Cain
Andi Snow-Weaver

Objection to General points

I am not quite sure I understand the text from "It allows roles to be overriden to ... is a child of the latter.)" One of the clarifications in the final last call drafts was to clarify the role characteristics table related to parent child relationships to change this property to SuperClass Role. In the case of menuitemradio and menuitemcheckbox, menuitemradio is a subclass of menuitemcheckbox as it does have an aria-checked state but for obvious reasons it has the additional restriction that only one can be checked at a time when it is part of a radiogroup. To further ensure ARIA is implemented correctly, ARIA specifies required children to ensure UI componentry to further structural accuracy of widgets. Now, since ARIA is used for dynamically generated content true validation proper semantic structure must be adhered to by validation at run time by a test tool that measures structural and semantic accuracy based on a combination of the ARIA annotation section in HTML 5 and the ARIA specification. No HTML validator will be able to check for complete accuracy of today's HTML applications without following a similar approach as today's user agents don't do runtime validation due to the overhead. The Open Ajax Alliance is, in fact, defining rules and working with the accessibility tools community to process the ARIA rules validation, as intended, while a web page is running.

Objection to: Allow links to be described as scroll bars, buttons to be described as progress bars, etc

Next to <div>, <a> is the most over re-purposed element in the HTML language. The main reasons for this are:

In HTML 4.01, ONLY forms and anchors are accessible. It was not until until the work on WAI-ARIA until we were able to take the tabindex implementation in IE where tabindex is applied to all HTML elements and it can receive a value of "-1" that this all changed. This has not been repeated in HTML 5 and this happened after IBM gave our first comments to the What WG HTML 5 specification and far before it came to the W3C. We worked with browser manufacturers to get that change implemented world wide. ... Yet, HTML 4.01 still does not specify tabindex in this fashion.
Since tabindex is not tied to a complex input control (text field, select, etc.) an easily override it and customize it any which way they like.
It can be placed in the tab order without applying a tabindex property to it.
Keyboard access is a fundamental requirement found in all web accessibility compliance criteria today. This includes WCAG 2, the 508 Refresh, etc.
A link can also have children so it is very easily to conceive how an author could convert an anchor to a scrollbar, slider, scrolling toolbar, etc. Simply intercept the keyboard input and you are off and running. It was this ability to create a customized UI that could be tied to back end services that caused the industry to converge to the Web. I would argue that all HTML 5 is doing is taking all that work and bolt them onto HTML. While there are clear benefits to this it is impractical to expect the HTML standard to stay ahead of the creativity of the rest of the Web. The editor's argument is almost saying that Apple should not have created <canvas> until he first puts it in his host language or that his own company should not have created a button in GMail out of a link.

Consequently, there are numerous implementations that overload an anchor to do things like act as a button to reveal an area, act as a button to perform an operation. Gmail uses links like this as does IBM's Lotus Connections.

Also, as the web progresses we are going to need to expand the semantics defined in ARIA. New UI constructs will be created and it will be essential that elements like anchors which have been used by authors to create custom controls have the ability to provide the appropriate accessibility semantics to them. Preventing ARIA's use on these elements would, in our mind render the host language inaccessible.

There is no person in the WAI that does not believe authors should use standard controls over custom controls to promote accessibility and to the extent HTML5 defines new controls types and they are used by developers it will reduce the need for developers to use ARIA in custom controls. The reason for this is that the browser should have already mapped them to platform accessibility services. Yet, it is not creation of WAI-ARIA that caused authors to repurpose HTML content. It was the author that decided to do this. It is simply unrealistic to suggest that HTML can predict and include every possible UI control that an author will invent and include a normative implementation in the host language. It is unrealistic to expect an author to wait for HTML to create and include one for them in the time frame they will need it. It is for these reasons that web accessibility guidelines were created in 1998 that prevented the use of CSS and JavaScript in web markup as it was deemed inaccessible. At this time, the people who developed HTML had not provided authors the ability to provide semantics to allow the author to convey their intent and subjected users to inaccessible content for years and subjected authors to unnecessary restrictions on the creation of content if you were to sell to a government agency. The editor of this counter-proposal was not subjected to these issues. He is not or visually impaired and is not impacted by government sales directly. It is for these reasons that WAI-ARIA has such world wide adoption and why we do not agree with the editors assertions that just because he builds it in developers will come.

Restricting ARIA's use on <a> will not prevent authors from using in alternative ways. The seeds to do so (script and CSS) are provided for in HTML. This is why we needed WAI-ARIA in the first place.

What the editor can be assured of is that accessibility people will encourage authors to use standard controls as it promotes accessibility and facilitates portability across systems. What we will not do is remove the declarative API (WAI-ARIA) to make their customized HTML mark up accessible as this does not promote accessibility.

For user agent that do not support JavaScript and CSS this discussion is rather moot. Developers will use standard control as they were defined and will not be able to change their use. In large part, ARIA would not be needed at all for these isolated situations.

Objection to: Allow an H1 element to be described as a spinbutton or checkbox, etc

What is preposterous is that the H1 element allows an author to apply script to it. As long as an author is allowed to apply script to an H1 then the author will do so. If H1 were truly ONLY used for a heading then absolutely no script would be needed. Yet, it is allowed. The editor was also provide an example on the Opera site where a heading was used as a button: http://dev.opera.com/forums/topic/165324

ARIA comes "after the fact". By "after the fact" is meant that an author has already re-purposed an html element to look and behave differently from its native semantic. Authors use CSS to render the element to appear other than its default, and JavaScript to make it behave differently. The element will have a look and feel that is unlike the markup semantic.

Worse, the element's representation in an accessibility API will differ from the author's intent. The accessibility API will publish information based solely on the markup. As a result, the experience for an assistive technology user is just plain wrong.

The way to correct the accessibility information is to annotate the element with the appropriate ARIA roles, states, and properties that reflect what the author has already done for the visual look and feel.

Thus ARIA's purpose is not to replace native semantics (hardly). Rather, it comes into play when native semantics have already been subverted, to convey the semantic that the author intended.

Consequently, whether we think an author should use a heading to create a control is irrelevant. Until the HTML specification removes the ability for the author to take an H1 and create a custom UI widget from it there is no guarantee that they won't. If there is truly no use case for this then simply remove the ability to add script to ALL the heading tags. We should also point out that a H1 tag can also receive keyboard focus through the use of tabindex. If it is simply a header then why allow it to receive keyboard input? It is our position that despite the intent of the H1 tag it is nothing more than a div with text, some unique styling, with the ability for the author to customize it in any way the choose. Stating that an author MUST NOT use an H1 for anything but an H1 is also not programmatically verifiable.

Unfortunately, the sad reality of accessibility is that if the author is given the tools to be creative they will be creative. Our requirement is to provide the tools for that author to make his/her creations accessible.

Objection to: Set the default role of IMG elements to ARIA's "img" value

There are some errors in this analysis. I will list them:

ARIA role="img" was introduced to handle the situation where multiple images are combined to form a single image. It was not created to apply role="img" on an image element. That is a waste of time when for all browser implementations today, an image has a role of img. We do not agree with the editor's implications that a role="img" is seldom necessary. It could also be used for a <canvas> implementation that only renders a drawing.
If the only disabled user on the planet were blind then one might think that the only purpose of image is to convey text. If you are a low vision user who is operating a page and is using a screen reader as well as a magnifier it would be incredibly confusing to have the screen reader tell them that an icon was text and not an image as a low vision user could also see the image with the help of a magnifier. It appears that the editor only interviewed a blind user.
While we agree that many images are indeed used for presentational purposes the host language calls them images and what is rendered is a picture. Consequently, the problem appears to be with the host language not properly defining an element called <spacer>, or <presentational> that defines a source that is an image vs. ARIA conveying the default role which is indeed an image.

The reason we have defaulted a role of image for <img> is simply because the host language gives the element a name of image and did so when the first accessibility API (MSAA) was created. At that time images were used more as pictures or images. RIA's were not developed back then so there was not a huge need for images to be used for spacing. Consequently all the assistive technology on Windows, the Mac, and Linux expect to see a role of image. If that were to change it would break all the AT implementations. It would break how they handle both old and new content. For these reasons we require the default role of image to be img.

Objection to: Request regarding the ARIA role of heading elements inside HGROUP elements

The current mapping in the spec removes semantic information for AT users only, by turning multiple headings into a single heading, there are no semantics conveyed about the 'subheadingness' of part of the hgroup content, any distinction has been removed in the role information exposed. Like browsers, other user agents must be able to choose how they represent the semantic structure of content to users, in order to do this the semantics must be exposed in the accessible tree as richly and as faithfully as is possible from the DOM. collapsing the semantics of multiple headings into a single heading level denies accessibility API clients this possibility.

Objection to: Why use cases are needed to justify allowing particular roles in particular situations

The HTML specification defeats its goal of "strong native semantics" by allowing authors to use JavaScript and CSS to modify any element in the host language and create an entirely new user experience that was not planned for. This was the case before WAI-ARIA was created and will continue to be the case until this changes. Also, the ARIA specification is only at version 1.0. We plan on expanding on ARIA 1.0 to handle new use cases on the Web that we cannot plan for today. It is unreasonable to think that any of us can foresee all the ways authors can and will modify HTML content to create new UI constructs. This is self-evident in the HTML host language whereby new controls like <details> were produced and there is no native host language mapping for it.

So, our concern is that to address this point, we would be asked to unnecessarily restrict ARIA today for what might happen in the future. This is how we got to where we are today. The person writing this comment did not go through the battles of our having to add ARIA:

- How can you add a role attribute? It does not validate? - How can you modify tabindex? It does not validate. - 9 months arguing over whether an aria attribute can have a hyphen, underscore, or ampersand delimitter

Meanwhile, while we arguing these (in the big picture) foolish discussions a whole group of people can't access the same Web you and I do.

What we have done, and what we believe is accurate is limit the use of aria where ARIA semantics actually break accessibility if used improperly such as overloading standard input controls where the ARIA state would interfere with the native host language state. For these situations we have stated that the role attribute cannot be used on specific elements.

Yet, if we state today that an element can only support roles a, b, and c and in ARIA 2.0 we need for the element to support role d. We have broken accessibility as we have unnecessarily restricted ARIAs use. That is also why we disagree that the editors "trivial" exercise of identifying all the use cases, for the purpose of limiting ARIA, is extremely short sighted. Limiting our use cases to what we know an author will do would break accessibility. We would also argue that many working on accessibility have stated that they do not want ARIA's use to be limited at all for these reasons and this is an unacceptable concession. We believe the editor should better spend his time limiting the use of JavaScript rather than ARIA.

To avoid repeating ourselves we ask that reviewers see our response to overriding the H1 - H6 elements.

Further objection to:Why use cases are needed to justify allowing particular roles in particular situations.

The HTML5 editor (Ian Hickson) goes to great lengths to inform us of the need for use cases to allow ARIA roles to be used in certain situations. This posturing on his part loses all credibility, when the rationales for the resolution of 2 ARIA related bugs are reveiwed:

1. allowing ARIA role=presentation on any element Note: only a few use cases were provided.

Rationale: It seems that the ARIA spec is very confused on this
issue, but in the interests of expediency, and under the assumption that the
ARIA spec will be corrected to match implementations, I've changed the spec to
allow role=presentation everywhere.

Since this decision by the editor it has been argued that role="presentation" should not be allowed on focusable elements as stated in the ARIA specification. No response from the editor has been forthcoming.

2. modify table, tr and td roles This bug was asking for a limited set of allowable roles on 3 elements.

Rationale: I gave up trying to understand this.

Check-in comment: remove anything to do with ARIA from the definitions of table
elements

What it ended up with was any roles allowed on the following elements table, tr, td, th, col, colgroup, thead, tfoot, tbody.

Objection to: Risks

This is clearly a difference in opinion between the editor and most of the developers out in the industry today. The reality is that authors wish to create their own custom UI's without the restrictions of the host language. Virtually every member's company in the HTML working group has product teams that choose to create their own custom UIs. They do not and will not wait for a small group of people to get around to adding their innovations to the HTML specification. Furthermore, such a specification would become so enormous and unwieldy that it would be incredibly difficult for authors to follow. In fact, many have expressed concerns over the size of the existing HTML 5 specification. What this comment is suggesting is that the world wait for the HTML authors to bolt on a businesse's custom controls to the HTML specification producing "a tag soup". That does not align with business needs nor does it align with anything practical. In fact, we would argue that the presence of javascript throughout the specification encourages this type of innovation. What we do support is the encouragement of authors to use standard HTML controls where possible. Notice that we said encourage and not mandate. Furthermore, prior to ARIA, the web had become increasingly inaccessible and unusable by people with disabilities - so far as to restrict the use of JavaScript and CSS in accessibility legislation. Authors followed what the HTML specification dictated and produced inaccessible applications leaving many without employment. ARIA, in a very large extent has changed that through the use of declarative markup that maps HTML content to match the intent of the author and it made it possible to remove restrictions on the use of JavaScript and CSS.

This is just an observation but amazingly the people who have complained most about ARIA being essentially bolt on "accessibility" in the ARIA comments are generally those people from companies who indeed have browsers with the least assistive technology support in the industry - even for basic HTML. ARIA has extensive world wide implementation. Apparently, the most of the rest of the world disagrees with the negative comment on ARIA above.

Comments on: Hicksons objections:

Web Developers Decide the Markup they will Use

In a perfect world there could be better controls on the markup developers use to create web pages and applications. Developers have various skills and knowledge and the computing environment and resources they have available to them all play a part in the coding patterns they use. Just because HTML 5 offers new opportunities to design web resources to be more accessible, but that does not mean that developers will totally recode their web pages to use those features. ARIA provides an alternative to totally recoding web pages to improve accessibility and will provide needed semantics of widgets not defined in HTML 5. The integration of ARIA into HTML 5 will provide developers with a clear path to migrate and update code to improve accessibility as they start to add HTML 5 to existing web resources already using ARIA. The main point is that ARIA provides critical functionality for accessibility now and as HTML 5 accessibility features become available developers can be encourage to use the HTML 5 native semantics and this will be easier if their is a clear relationship between ARIA features and HTML 5 features to support accessibility.

Response to: Objections to the rationale's introduction

Unfortunately, Ian's rebuttal misses the entire reason why we need ARIA:

First, let us state that the inclusion of additional built in UI constructs in HTML 5 is an improvement in accessibility push some of the accessibility in these UI components to the browser. We believe this happened, in part, due to the ARIA working group sharing early drafts of the ARIA specification with the WhatWG. In this sense, HTML 5 is better than HTML 4 for accessibility. Yet, the editor blames ARIA for violating HTML semantics when in fact the HTML design has encouraged authors to break (Ian's interpretation of) HTML's design philosophy). HTML elements allow the author to use script and CSS to create new custom UI components and did so far before a group of people got together to create a new version of HTML. Once you allow for an author to re-purpose an HTML element you have allowed the author to change the "semantics for that element." The authors of HTML did not foresee this happening. Yet, the web development community found an intense need to deliver a rich internet application experience that could be delivered and customized to desktops, mobile browsers, kiosks, etc. throughout the world. Many of the UI components did not even exist in HTML, consequently, the user agents did not have the necessary semantics to convey the intent of the author to an assistive technology and HTML did not provide the vehicle. This had absolutely nothing to do with ARIA. In fact, nobody had a clue how to address the resulting accessibility issue. As a result of this problem, Web accessibility compliance criteria throughout the world prohibited the use of JavaScript and CSS making large IT providers, like IBM, unable to sell product with a rich usable experience to its customers. Rich Schwerdtfeger was asked to solve the problem as billions of dollars in software revenue at IBM and other companies, like it, were at stake as was the satisfaction of its customers. Consequently, Rich came up with the technology, that is now W3C's WAI-ARIA specification (and which has contributions from industry, higher education, and disabled users world wide) to provide the author with the ability to convey the semantics, intended by the author to an assistive technology. ARIA has garnered enormous world wide adoption as it has allowed creative authors to produce content, fully allowed by HTML, to be accessible.

Developers are not confused about HTML messaging on semantics. They know full well what they are doing. They are creating UIs that differentiate their products from others. To hear Ian spout on about how disastrous our proposal is outlandish. Rich comment: IBM and industry has never experienced such an increase in accessibility on the Web as they have with WAI-ARIA. We use it in hundreds of IBM products and it has cut our software enablement time from desktop applications by 80%. It is being implemented in ALL the major browsers (including Google's Chrome browser) and it is being applied by almost every major corporation in the industry today in some degree or form to produce accessible web IT.

Authors must have the ability to innovate and produce custom UI componentry - even if HTML has a standard control in it that has similar function. Developers world wide are not going to wait to vet all their use cases through Ian Hickson to be incorporated in the next version of HTML. That is why his arguments are ill-founded and impractical. What we will say is that if it is possible for a developer to use a standard control in HTML they will do so if the business reasons warrant it. Certainly, from an accessibility perspective there is much less work to do and anyone who works in accessibility would encourage it. Yet, developers still produce their own custom components. That is why we need ARIA and why we have tailored our change proposal in such a way that it encourages authors to use standard HTML elements as defined but does not prohibit customization. We have ARIA available to address that need.

The assertion that ARIA violates HTML semantics is in error:

ARIA does not violate the semantics of an element. The author does so when he/she re-purposes the element using JavaScript and CSS. ARIA is available to allow the author to convey their intent. If ARIA where not included authors would still "violate" the specification. This has already been proven and it is the reason legislation has prohibited the use of JavaScript and CSS. The problem of validation is two-fold: Much of what is created today is generated by JavaScript in the browser, bypassing any validation tool. Furthermore, no browser is going to validate content at run time as it is a performance disaster. So, the author can re-purpose HTML using JavaScript in the browser. Without ARIA, Ian and most people on the web can work with the web page just fine as the UI was design to meet THEIR needs. Now if you remove ARIA these same re-purposed UI components are inaccessible to those for whom the UI was not designed.

The HTML5 spec does not propose to validate against CSS and JS violations, only ARIA violations. The spec proposes to tell authors they have made mistake only after they add ARIA, and not when they add event handlers. Event handlers are what changes the semantic, ARIA simply attempts to catch the AT up with those changes.
Teaching people about semantics is not the goal of ARIA. Making content accessible is the goal of ARIA. ARIA addresses the issue that 15+ years of attempting to teach semantics to web authors has failed.
Ian asserts that we have relaxed or removed ARIA restrictions. This is a generalization that lacks understanding of the issues at hand. It is he himself that has completetly relaxed restrictions on a range of elements without due reason.

In actual fact the working group went a very long way to increase ARIA's restrictive use but only to the point where its semantics would interfere with the native UI component where states were involved. Yes, in some cases we relaxed the restrictions. For example, the anchor tag is used extensively in industry for backward compatibility as only it and HTML 4 form elements were the only keyboard navigable elements in HTML 4. Authors frequently re-purpose a link for their needs using JavaScript and CSS. It was not until the people working on ARIA drove IE's implementtation of tabindex into all the browser that this changed. In fact, an early version of the ARIA specification was given to the What Wg and many ARIA specification concepts like tabindex, aria-required, and some navigation landmarks were incorporated in some form into HTML 5.

Also, elements like <h1> can easily be re-purposed and often has been using for styling on the Web yet, despite how it is used today, the editor decided to require user agents to use headings to generate a table of contents and expects the Web to work consistently. This is a bit naive to say the least. What we have provided with ARIA is a vehicle such that if the author is to re-purpose a heading they can apply the appropriate ARIA semantics and assist the browser in choosing the right heading to appear in the table of contents. Yet, the specification ignores that capability.

Ian's assertion that ARIA is as much a markup as HTML is absurd

ARIA is semantic markup that allows the author to provide intended semantics of the user interface, when the original HTML elements did not satisfy their need, to a user agent so that it may support platform accessibility API services. It contains NO elements. It does NOT direct the browser how to render content. It is simply a declarative accessibility API that allows the author to use their existing UI implementation and while feeding platform accessibility API services. Consequently, adding ARIA to an existing code base is a much lower-risk change than rewriting the HTML. A real world example of this is ARIA's use in Yahoo mail. When you’re talking about your personal web site, of course you *can* change it. A larger organization can also change it, but it must compete with other priorities. However, the cost and risk of replacing the UI of a site with new HTML are high enough that many organizations will find them unacceptable. ARIA allows developers to add accessibility info without having to change anything else about how the site works. ARIA provides a lighter-weight, lower-cost, less-invasive mechanism for conveying the existing semanitics to AT, without requiring that the underlying structure be re-written and re-tested. In most cases, only the new ARIA functionality must be tested, while existing non-AT scenarios will continue to work as they did before.

Ian's assertions about the ARIA taxonomy are technically inaccurate. He confuses sub-classing with structural requirements for widgets:

"However, this is trivially disprovable by example: the "radio" role is a child of the "checkbox" role, yet these are not interchangeable native HTML concepts" - A radio button is a subclass of a checkbox and not a required child of a checkbox. It subclasses checkbox because it is checkable, inherits the checkbox supported states but has the additional restriction that only one of a group can be selected at the same time. The ARIA subteam actually spent considerable amount of time on our inheritance model getting this all right.
"similarly, his comment: the "listitem" role, which requires a "list" parent in the DOM, has as a child role the "treeitem" role, which requires a "group" or "tree" parent, so again these are clearly not interchangeable." Here again, Ian is confusing subclassing with required structural constructs for components. The only thing we can think of is that Ian is operating off a much earlier version of the specification where this was unclear as we don't believe that Ian does not understand the difference between a subclass and required children or parents. A treeitem is a subclass of a listitem as a treeitem inherits the states and properties from a list item. However, a treeitem has additional hierarchical requirements in that it can reside in a tree or a group. Nowhere in the specification does it state that a treeitem "child" of a listitem.

Response to: Objections to "basis for changes to command roles"

In Ians obection he has asked for use cases for why and when an author would take existing HTML elements like anchor and button and re-purpose the element to produce new controls to justify applying ARIA markup to them. The bottom line is that HTML 4 only provided a handful of controls that were keyboard accessible (form elements and the anchor tag). ALL other elements were not keyboard accessible. Consequently, authors use these HTML 4 keyboard accessible elements extensively throughout the Web. The most commonly used is the anchor tag. Both button and anchor a fairly uncomplicated so it is easy to take these elements and produce a new widget using JavaScript and CSS. However, it is a pointless and impractical effort to predict every possible use case that an author is going to manipulate the UI control to produce a new UI construct. Since it is pointless to predict every possible use case that a developer can come up with we refuse to open up the accessibility worm hole introduced in HTML 4 by removing the ability to provide accessibility interoperability semantics content that we believe can be modified by authors to form new UI elements. I think it would be more beneficial for the editor to actually go to his own product development team who produce GMail and ask them why his own company's premier email developers chose to uses divs and spans to create buttons vs. using the standard HTML button. We are sure that he will quickly find, as Rich and Cynthia have found at their companies, and Steve has found in his consulting engagements that authors want to produce their own custom UIs without being told what to do by a small set of people, especially when HTML provides JavaScript and CSS support to do so. Furthermore, if accessibility engineers were to tell the author that they MUST use the standard control to be accessible this would further draw a wedge between accessibility engineers at companies and the developers that create web applications. More importantly, as evidenced by GMail, and numerous other products that does not work.

How is graceful degradation in mixed environments not a use case?

Response to: Objections to "basis for changes to allowed roles on the a element"

Note: The claims that some of the examples in the change proposal do not include any ARIA are mostly false as the claimant knows.

Ian indicates that in the jQuery demo the http://jqueryui.com/demos/dialog/

"there is non-conforming HTML in that it uses a link where a buttton would be more appropriate (closing a dialog is not a link)"

There are a number of problems with this assertion that Ian is choosing to ignore and furthermore he is ignored the other accessibility issues that ARIA has fixed (these can be seen using the accProbe accessibility test too with Firefox which I would be happy to show the chairs):

The author apparently felt that providing a seemless UI in the dialog frame was too difficult using the standard control. JavaScript provided a simple way to apply script and CSS to the link to give it the look required.
ARIA was applied to the link with a simple attribute of role="pushbutton" and provided a label called "close" and it works fine
ARIA supports a dialog role that was applied to the dialog container. If we did not have it there is no construct in HTML to convey that the user has entered a dialog. HTML 5 has no dialog construct.
ARIA provides an aria-describedby property that was applied to the dialog to point to the message in the dialog box so that it is announced to a blind user when the dialog announces. HTML 5 does not provide an explicit way to assign this relationship.

So, what are we to do rip out ARIA and wait for the HTML working group to include all these features so that some day an author will have everything they need such that they can be applied in a malleable fashion to meet all their needs?

Ian claims that this http://developer.yahoo.com/yui/examples/carousel/carousel-ariaplugin_source.html

 "Despite claims to the contrary both in the CP and in the source of
 the page, this document does not in fact appear to use the role
 attribute. The comment in the source points out a couple of reasons
 why using a link for a button is a bad idea, too."

We looked at this page and in fact the carousel that you see has a role="listbox" and each element in it has a role of "option" as is required - meaning the author added the ARIA semantics to the DOM, using JavaScript, after the page started to load. We inspected this with Firebug and we inspected it with accProbe to make sure that the accessibility APIs are mapped properly. We are unaware of a listbox in HTML that looks like this so it is likely that the author created their own custom carousal that behaves like a listbox. A blind user does not care how it looks as long as they can operate it like something they are familiar with. It is for these reasons that we need ARIA. An excellent example. Thank you Ian. You must look at these things at run time. The ARIA markup was added at run time. One reason for this is they may not have had a DTD that included ARIA to do validation. This is solved by adding ARIA markup at document load time.

http://developer.yahoo.com/yui/examples/tabview/tabview-ariaplugin_clean.html

 I wasn't able to find any ARIA in use on this page. The links that
 would presumably be marked as buttons on this page are better
 presented as links, so it's not clear that this provides a use case
 anyway.

We looked at this page as well. Run Firebug and search for tablist. You will find a role of tablist. Ian is incorrect in his assertions. The UI construct is a notebook with tabs contained in a tablist followed by a tabpanel. These additional containers provide contextual information that a user is familiar with on the desktop. It is all marked up with ARIA, easy to use, and operates for a blind user the same way it does for a sighted user. Also, using links breaks usability and creates another usability problem. Using links instead of notebook tabs in a tablist requires the user to have to navigate a heavily polluted tab order vs. quickly tabbing to a tablist, using the arrow keys to navigate within it and then tabbing out of the tab list (skipping all the other tabs in the tablist). This make navigation much faster and benefits non-disabled keyboard users. Unfortunately, Ian's objections are actually making the case stronger for ARIA by highlighting the limitations of the standard controls in HTML 5.

*  http://developer.yahoo.com/yui/examples/menu/menuwaiaria_source.html
 Again, there does not appear to be any ARIA on this page, but in any
 case it's not clear that any role other than menuitem="" would be
 appropriate for the items in this menu. (menuitem="" is the role the
 HTML spec would enforce on pages that marked this up correctly using
 the "menu" and "a" elements.)

We ran this page and launched Firebug (which is also enabled using WAI-ARIA). If you will search for menubar in the HTML view you will find a role of menubar on the menubar and a role of menuitem on each of the menuitems with an aria-haspopup property on menuitems that have sub menus. Again, this is a menubar and not a menu. The ARIA specification specificies that menu or menubar must have one or more of menitem, menuitemradio, menuitemcheckbox. WAI-ARIA accessibility test tools that make use of the Open Ajax Alliance Accessibility Rule sets for WCAG 2 include rules that use these ARIA structural requirements like these to enforce WCAG 2's Robust (Guideline 4) requirements when used on HTML 4. If the author has implemented the design pattern enforced by the ARIA specification a WCAG 2 failure will be generated in the report. These rules are being adopted by Rational Policy Tester, ParaSoft web accessibility checkers, Deque WorldSpace, and people working on the French government's WCAG 2 compliance test tools as a start.

 * http://jqueryui.com/demos/slider/
 It would be quite inappropriate for the demo on this page to use a
 _link_ for its UI (the tabindex="" attribute in conjunction with a
 "div" would be much more appropriate). In any case HTML already
 provides for this semantic natively ("input type=range").

This illustrates backward compatibility to older browsers. Link is keyboard accessible in HTML 4 where divs are not. You will find links used extensively for these purposes throughout the Web.

* http://masinter.blogspot.com/
 HTML already provides checkboxes; using links for that semantic is a
 misuse of HTML.

The sentence in the change proposal preceeding the list of examples states: "Examples of the a element being repurposed in popular JavaScript UI libraries" it did not claim that every example incuded ARIA, this one did not, but it would obviously benefit from the addition of ARIA to help the users make sense of the the semantics. The author made these changes to produce a checkbox. If need be they will simply generate the content when the page loads and ignore Ian's fist pounding about what is a misuse of HTML. This is note even an ARIA discussion.

* http://www.jstree.com/demo
 Using links for this semantic is again a misuse of HTML. The "div"
 element is the appropriate element to use for creating widgets of
 this nature.

Same argument as previous. If the HTML chairs agree to restrict ARIA on a link it will break accessibility for users all over the Web. Links are customized extensively by web developers. We are seeing a recurring theme here. Ian wants to restrict authors use of HTML by penalizing ARIA for it and harming people with disabilities. That is absurd.

* GMail's buttons made from links
 GMail mostly uses "div"s for its buttons, but in any case the CP is
 correct: GMail should not use links for buttons.

So, why has Ian not stopped the GMail team from doing this? The GMail team knows about ARIA and they know about HTML 5. We do know the gmail team is very concerned about download footprint. If you use a div you now need to apply a tabindex. This adds characters to the download. Ian can't possibly sit in everyone's office and dictate to them how to write HTML code and neither can accessibility engineers. Even if we could we are not going to tell people how to produce business applications. They have different motivation factors for doing what they are doing. The engineer can make the link look like a button and in those cases they can ARIA markup to make it accessible. Those of us in accessibility would be more than happy if Google could have used a button here - but they did not. That is why ARIA is needed and it can be applied without changing the visual appearance of the UI control.

Ian's comment: "The CP goes on to admit that the "a" element isn't necessary for these use

cases, and that "div" will work fine. But it then says that the change to the HTML5 spec is needed to work around the lack of a fix to the _HTML4_ spec; a fix that has already been applied to the HTML5 spec (and thus would take effect at the same time as the workaround, and no later) and that has already been widely implemented."

The specification does not prevent an author from generating content in the browser and re-purposing the anchor tag. Has HTML 5 removed the ability to apply script and CSS to an anchor?

Ian's comment: "Finally, the CP in this section repeats the assertion that HTML's

authoring conformance criteria in one section will be ignored, and that therefore conformance criteria in another section must be loosened to allow authors to work around their mistakes. This is self-contradictory. Either authors will follow the spec, in which case they won't need to the loosened requirements proposed, or they won't, in which case the entire discussion is moot since authors will ignore both the ARIA-related conformance criteria _and_ the more fundamental requirements related to correct use of elements."

Authors will follow ARIA conformance criteria if they want to support assistive technologies. If they don't why would they bother with ARIA at all? An author can ignore HTML conformance criteria simply by generating the code in the browser. Telling someone that they cannot do something vs. programmatically prohibiting it is an entirely different discussion. The HTML 5 specification still allows the author to ignore the fist pounding by Ian and generate content in the browser. Since they can do this then we should allow ARIA in markup where it does not interfere with the accessibility API mapping of state information. This we have addressed in our change proposal.

Response to: Objections to "basis for allowing roles on heading elements (H1-H6)"

"Contrary to some of the statements in this section, it is not "perfectly valid HTML markup" to use script on these elements if the result is an abuse of the element's semantics. The role="" attribute gives us the unique opportunity to catch this particular error as a syntax error. This is a good thing, not a problem."

Yet the HTML specification allows the event handlers on the H1-H6 elements. Remove them! If you don't you are not enforcing your semantics and allowing authors to do what they want.

* Ian's comment: "This section also makes the argument that we have to make particular ARIA 
constructs valid because if they're not valid authors won't use them, 
while simultaneously arguing that we need them to be used because authors 
are going to ignore other conformance requirements. Either authors are 
going to follow conformance requirements, or they are not. If they are, 
then the issue raised in this section does not come up. If they are not, 
then there is nothing we can do to authoring requirements that will make 
any difference."

First, it is Ian that wants to make ARIA's use invalid and, second, HTML's ability to enforce conformance requirements is poor. All the elements Ian wants ARIA to be prohibited on allow for script and CSS to be applied. If it is allowed then authors will use it to produce custom controls. When that happens they become inaccessible. What is being suggested is that to change the UI and conform to Ian's mandates that the author has to change their UI for it to be accessible. That will set accessibility back and sets accessibility up for being the whipping child for Ian's conformance criteria. That is unacceptable. If Ian truly believes in mandating his conformance criteria on developers then he needs to remove JavaScript support from HTML 5. We know that this won't happen as it will drive developers away from HTML. In the mean time we need ARIA for accessibility as we have proposed in our replacement to the ARIA section and as accessibility people we will encourage developers to use standard HTML 5 controls as is. However, you have to ask yourself if it is so hard to get developers to use links and headings the way Ian intends them how hard is it going to be to mandate that they use more complex HTML controls?

* Ian's comment: "Finally, this section provides an example where a heading, which in the 
graphical representation looks like a heading, acts like a heading, and 
gives no indication of being anything but a heading, happens to have an 
onclick="" handler. It is subsequently argued that in ATs, this heading 
should in fact appear to be a button. However, that would be quite 
confusing to any AT user. For example, should a friend of the reader's 
refer to the heading as a heading, the AT user would have no way to know 
which heading their friend was referring to. The heading in this example 
isn't a button. Exposing it as a button to ATs would be a bug."

Well if you don't expose it as a button (an active element that performs a single action) then a blind user will not know that activating it will do something. A header is the wrong semantics for the element if that is what the author wanted. Blind users don't walk around with Wiji board to determine how to operate elements. If I were told something was a header I would have no idea that it would be launching a dialog. Ian poses an outrageous argument.

Response to: Objections to "basis for defining h1 to h6 element that does have an hgroup ancestor"

* Ians comment: The proposal in fact suggests making the hgroup element have no role, and 
transferring the heading role to the child of hgroup with the highest 
rank. This fails to handle the case of there being multiple such elements, 
and further means that in the ARIA tree, the subheadings are demoted to 
the status of regular paragraphs, which is a significantly worse 
degradation of the semantics than making all the subheadings of equivalent 
weight in the ARIA rendering.

Having no default ARIA role does not mean there will be no API mappings, it merely means that the API mapping is dictated by the HTML5 specification.
there is no such construct as the "ARIA tree"
The degradation of the semantics is due to the poor design of the hgroup element, nothing else.

response to: Objections to "basis for the img elements default role being img"

Ians comment:

"It is true that we should not mandate UI for any user agents -- and the 
role="" attribute does not. Mapping or not mapping an element to 
role="img" does deny ATs "the ability to offer users a preference about 
what role information they can receive"; if it did, then we would be 
mandating UI, which we should not, just as the CP says."

If the role information is not conveyed via an accessibility API, the AT will not be provided the role information. It has been stated by the HTML5 editor that if a browser vendor chose to map the img element to an image role in a platform accessibility API such as MSAA, the browser would not be conforming to the HTML5 specification, how is that NOT mandating UI?

Response to: Objections to the "Positive Effects" section