This Wiki page is edited by participants of the HTML Accessibility Task Force. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Task Force participants, WAI, or W3C. It may also have some very useful information.
Results of Spec Review
From HTML accessibility task force Wiki
Below is a table of results from the first of two sessions in which participants in the HTML Accessibility Task Force walked through the HTML5 spec in an attempt to identify sections marked as Interoperable that may require testing to prove they do not have any accessibility problems associated with them. This work is in response to a CfC from the HTML Working Group. The CfC comment period closes on Monday July 15, 2013.
Requirements set forth in the CfC state that "Objections of the form 'features in 2.8.2.1 HTMLAllCollection are not currently interoperable' MUST be accompanied with specific evidence of non-interoperability, otherwise such objections will not be accepted by the Chairs."
Please use the table below to document specific evidence of non-interoperability. You may also send additional feedback to mark@w3.org
| Section of spec | Current Status | Notes | Evidence |
|---|---|---|---|
| 2.5.6 Colors | Interoperable | Researched by Leonie This is the section that excludes CSS2 colours, but whether that is an interoperability issue is perhaps another matter. Not happy about CSS2 System Colors being deprecated, Test to see if system colors are currently implemented. MS: Not sure if this is the appropriate venue for this issue. While we are not happy that System Colors has been deprecated, it cannot be resolved with testing. I believe 2.5.6 Colors is interoperable as it is currently defined in the spec. |
Bug: CSS2 system colors should be recognized |
| 2.5.10 Media queries | Interoperable | We expect them to be used for a11y purposes so so we should test them and make sure they work as expected. MS: Since 2.5.10 Media Queries is a subsection of Microsyntaxes and only addresses how media queries are included/parsed from a syntactical perspective, can our concerns be addressed by testing? While Media Queries do see to be of concern for accessibility, I'm not sure this is where we would make this case. CSS3 Seems a much more appropriate venue for this. |
|
| 3.2.3.2 The title attribute | Interoperable | Some questions regarding what the spec says. Any problems implementing the spec? Is it interoperable? Anyone know of specific issues? | The title attribute, while widely implemented, is not implemented in a consistent or accessible manner. The HTML spec acknowledges this in a Note [3] contained at the beginning of this section. The TF believes this attribute requires interoperability testing. |
| 3.2.3.3 The lang and xml:lang attributes | Interoperable | Some discussion about improper usage. Anyone know of specific issues? | Screen readers can use the lang attribute to perform language switching, allowing speech in the natural language specified. Since this attribute can be used on any element, the TF thinks testing is required to insure its value is available to all user agents. |
| 3.2.5.2 Transparent content models | Interoperable | Transparent content models - this comes into play with accessible fallbacks of things like <object> I think. I'm not sure where things stand with elements that use this, but if any elements we care about do, we probably do want to test this. | The "transparency" of an element depends on its context or usage. Most fallback content can be considered "transparent" as it inherits the context of its parent element. The "re-mapping" of an element's content model must be properly conveyed in the DOM to insure that Access Technology (AT) can properly modify the element's behavior and provide the appropriate access to it. As far as we are aware, there have not been any tests designed to verify this. |
| 3.2.7 WAI-ARIA | Interoperable | Rich Schwerdtfeger's feedback from second meeting minutes. | |
| 3.2.7.3 Strong Native Semantics | Interoperable | Reported by SteveF Noted that this may best be taken up in IndieUI or PF (ARIA) | The TF believes at least some of the implementation requirements in these sections are either not interoperably implemented or require testing to demonstrate that they are. For example:
|
| 3.2.7.4 Implicit ARIA Semantics | Interoperable | See Above | |
| 4.4.11.1 Creating an outline | At Risk | needs a11y testing if it stays in the spec | |
| 4.6.2 The em element | Interoperable | Requires a closer look since purpose has changed. Anyone know of specific issues? | |
| 4.6.3 The strong element | Interoperable | Requires a closer look since purpose has changed. Anyone know of specific issues? | |
| 4.6.5 The s element | Interoperable | Not well supported by AT. Anyone know of specific issues? | |
| 4.8.1 The img element | Interoperable | Should we look more closely at this? srcset perhaps? Any other interoperability issues? SteveF? MS: Steve does not believe there are any issues with img other than the one we previously used as an example in ARIA strong native semantics RE: img role:presentation. |
|
| 4.5.11 The figure element | Has implementations | needs a11y testing | |
| 4.5.12 The figcaption element | Has implementations | needs a11y testing | |
| 4.7 Edits | Has implementations | needs a11y testing | |
| 4.8.6 The video element | Has Tests and Implementations | need extensive a11y testing | |
| 4.8.7 The audio element | Has Tests and Implementations | need extensive a11y testing | |
| 4.8.8 The source element | Has Tests and Implementations | need extensive a11y testing | |
| 4.8.9 The track element | Has implementations | need extensive a11y testing | |
| 4.8.10 Media elements | Has Tests and Implementations | need extensive a11y testing | |
| 4.8.11 The canvas element | Has Tests and Implementations | needs a11y testing | |
| 4.8.14.2 Processing model | Interoperable | Need to follow up on this. Open bug that chaals was looking into. Anyone know of specific issues? | The TF has an issue with the spec text that makes an exception for how `<object>` elements are to be processed by user agents which do not support images. The TF would like to see this issue resolved and the behavior tested in user agents as it affects the accessibility of imagemaps contained in `<object>` elements. |
| 4.9.1.1 Techniques for describing tables | Interoperable | Researched by Dave MacDonald: HTML5 a11y replacements for Table Summary attribute don't work in JAWS and NVDA in IE Chrome, and Firefox browsers. Debate as to whether this is a problem with HTML5 spec or poor implementation by screen readers: Re: HTML5 alternatives to table summary... | Demo: How well do the HTML 5 replacements for table summary attribute work with current Screen Readers and Browsers? Rich Schwerdtfeger reminded us to check that the summary attribute is no longer mapped in the AAPI. |
| 4.9.2 The caption element | Interoperable | Oracle if caption is longer than width of the page it cuts off table. Should follow up on this, code in the example. | |
| 4.10.4 The fieldset element | Has Implementations | Leonie seemed to think there were some inconsistencies with how fieldset and legend are implemented across browsers | |
| 4.10.5 The legend element | Interoperable | See above | |
| 4.10.7 The input element | Needs Tests | needs a11y testing, especially testing that the new states work for a11y not just mainstream. | |
| 4.10.7.3.1 The autocomplete attribute | Needs Tests | test when aria autocomplete metadata is in the markup. | |
| 4.10.8 The button element | Interoperable | test the new attributes at least? | The TF believes that while the button element has existed for quite some time and is widely considered to be interoperable, there are many new attributes available on this element that may have an impact on accessibility (autofocus, formnovalidate, etc.). |
| 4.10.21 Constraints | Has implementations | We might care about because it impacts form validation I think. | |
| 4.11 Interactive elements | Everything in 4.11 could be important for a11y testing if it's going to remain in the spec | ||
| 4.12 Links | Interoperable | test keyboard navigation for links. | Given that links are a critical component of the web and that the ability to navigate to them with the keyboard in all appropriate contexts is critical to users of AT (i.e. when they are used in fallback content) the TF believes that the keyboard accessibility of links be tested, especially when used in the context of fallback content. |
| 4.12.5 Link types | Interoperable | As Michael understands it, link types used to be supported on the <link> element but are now supported on <a> as well. I think that's a change, or at any rate is more extensive. Testing these might not be vital - I think the <a> should still work, but they provide accessibility benefits it would be desirable to test. | While link types have been considered widely interoperable, HTML5 now supports the the use of of link type on the `<a>` and `<area>` elements in addition to the `<link>` element. The TF believes testing is required to determine interoperability of this new feature of HTML5. |
| 4.13.3 Tag clouds | Interoperable | <chaals> Not so sure that font-size is interoperable. People use minimum-font-size which would blow it away MS: This is going to be hard to argue for testing since this section is not normative. We should file a bug if we think the examples can be improved. |
The TF believes that testing is required of the example given to markup a tag cloud. The TF does not believe the `font-size` property is interoperable, particularly if used in conjunction with a user override of min-font-size. |
| 4.13.4 Conversations | Interoperable | <chaals> this is just an acknowledgement that html doesn't work well for this. Not sure how interoperable the examples are. I don't think they are particularly clear and I would appreciate someone else looking over them MS: This is going to be hard to argue for testing since this section is not normative. We should file a bug if we think the examples can be improved. |
|
| 7.2 Inert subtrees | Interoperable | RS: anything that is hidden is inert. this is hidden content. been around for a long time. however, the hidden attribute, IE 10 doesn't support it. so it should be tested. another form of inert is a modal dialog box. keyboard navigation should not go to anything below that dialog box. should also mean that you cannot do a programmatic click on those things either. test the javascript access to those elements as well. if its hidden, it can't be mapped to the AAPI one problem is that IE does not implement the hidden attribute in IE10. So technically that content should be inert but it is not also, inert content should not be in the keyboard navigation order, should not respond to click() focus() or blur() Robin said that inert subtrees is different from hidden content and that hidden content is marked as needing testing. |
|
| 7.4 Focus | Has implementations | Critical to make sure testing isn't short-changed, and we may want to go out of our way to do a11y-specific testing here. RS: keyboard navigation. when you tab and land into fallback content, that you are getting focus on elements in the fallback content. What happens if you put a widget in the fall back content?? | |
| 7.5 Assigning keyboard shortcuts | Has implementations | needs a11y testing | |
| 7.6 Editing | Has implementations | needs a11y testing | |
| 7.7 Drag and drop | Has implementations | needs a11y testing | |
| 10.2 The CSS user agent style sheet and presentational hints | Interoperable | RS: CSS produced content, is it accessible? MS: CSS generated content is not accessible. <chaals> CSS content isn't interoperably accessibile as far as I know.<chaals> some browsers made it available (e.g. Opera pre-blink) but I think most didn't and argued that wasn't a bug. MS: This section of the spec refers to default styles used when no styles are defined by the author, not content added to the DOM using CSS like :before, etc. I don't think there are any interoperability issues here. |