From HTML WG Wiki
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.
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.
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
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.
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.
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
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.
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 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:
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:
- 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.
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"
- 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):
- 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."
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.
* 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."
* 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"
"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
"the specification includes text (which is even included in this change proposal's proposed replacement text!) to ensure that conformance checkers do not lay the blame with ARIA attribute usage."
- There is no surity in this spec text it is merely a suggestion.
- It doesn’t matter what the error message says. Developers will learn that adding ARIA causes bunches of validator errors and warnings, where adding event handlers does not. This will discourage adoption of ARIA.
- The conformance requirements for use of CSS and correct semantics don’t generate validator warnings, so authors won’t be confronted with them.