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.

Simon Harper

Looks fine however I'd like to highlight - Other Applicable Specifications - which without some form of accessibility semantics built into the additional spec description could be a problem in the future.

James Craig

User agents that process HTML and XHTML documents purely to render non-interactive versions of them must comply to the same conformance criteria as Web browsers, except that they are exempt from requirements regarding user interaction.

Typical examples of non-interactive presentation user agents are printers (static UAs) and overhead displays (dynamic UAs). It is expected that most static non-interactive presentation user agents will also opt to lack scripting support.

A non-interactive but dynamic presentation UA would still execute scripts, allowing forms to be dynamically submitted, and so forth. However, since the concept of "focus" is irrelevant when the user cannot interact with the document, the UA would not need to support any of the focus-related DOM APIs.

The HTML TF should consider if there are any other implications for assistive technology. For example, would exporting to a print-formatted file be considered a non-interactive presentation, and may there be opportunity for assistive technology to interact with the file in another context like a word processor or e-book reader? If so, some of the focus management capabilities may need to be maintained.

User agents, whether interactive or not, may be designated (possibly as a user option) as supporting the suggested default rendering defined by this specification.

User agents that are designated as supporting the suggested default rendering must implement the rules in the rendering section that that section defines as the behavior that user agents are expected to implement.

I suggest adding a sentence explicitly stating that a user agent or assistive technology may override the suggested default rendering (e.g. color, font-size, focus style) for the sake of accessibility, readability, or other personal preference. Then again, this is is loosely implied by the first paragraph, so it may not be necessary.

However, WYSIWYG tools are legitimate. WYSIWYG tools should use elements they know are appropriate, and should not use elements that they do not know to be appropriate. This might in certain extreme cases mean limiting the use of flow elements to just a few elements, like div, b, i, and span and making liberal use of the style attribute.

This means authoring tools are explicitly required to not use semantic markup in places where there is any ambiguity. While the idealistic purity of the requirement is admirable, it seems rather impractical with regards to encouraging the creation of highly inaccessible content. The HTML TF and ATAG WG should discuss this point.

discuss

All authoring tools, whether WYSIWYG or not, should make a best effort attempt at enabling users to create well-structured, semantically rich, media-independent content.

Authors can create plugins and invoke them using the embed element. This is how Flash works.

Embed? Is the object element deprecated for this purpose? I seem to recall there is better accessibility support for object than embed. Last I checked, Flash was exporting with a preference for object, with embed only used as the legacy fallback (for Netscape 4!). Admittedly, this may have changed, since I haven't authored Flash in the last 7 years or so.

The conformance terminology for documents depends on the nature of the changes introduced by such applicable specificactions, and on the content and intended interpretation of the document. Applicable specifications MAY define new document content (e.g. a foobar element), MAY prohibit certain otherwise conforming content (e.g. prohibit use of <table>s), or MAY change the semantics, DOM mappings, or other processing rules for content defined in this specification. Whether a document is or is not a conforming HTML5 document does not depend on the use of applicable specifications: if the syntax and semantics of a given conforming HTML5 documentdocument is unchanged by the use of applicable specification(s), then that document remains a conforming HTML5 document. If the semantics or processing of a given (otherwise conforming) document is changed by use of applicable specification(s), then it is not a conforming HTML5 document. For such cases, the applicable specifications SHOULD define conformance terminology.

This may not be an issue, since it claims removing support would make it non-conforming HTML, but this seems to open other document formats that implement part of HTML (EPUB for example) to explicitly forbid certain features of the language, to prohibit or change the processing rules for certain features, such as ARIA or other accessibility features. The HTML TF should review this section.

Greg Lowney

The current draft HTML5 spec says:

Non-interactive presentation user agents

User agents that process HTML and XHTML documents purely to render non-interactive versions of them must comply to the same conformance criteria as Web browsers, except that they are exempt from requirements regarding user interaction.

Typical examples of non-interactive presentation user agents are printers (static UAs) and overhead displays (dynamic UAs). It is expected that most static non-interactive presentation user agents will also opt to lack scripting support.

A non-interactive but dynamic presentation UA would still execute scripts, allowing forms to be dynamically submitted, and so forth. However, since the concept of "focus" is irrelevant when the user cannot interact with the document, the UA would not need to support any of the focus-related DOM APIs.

It is very important that developers should not relegate user agents to the "non-interactive" category if there is benefit to the user in being able to interact with them.

Use case: Imelda uses a screen enlarger. She runs an application that displays a static, web-based slide detailing today's weather forecast. Imelda uses a screen enlarger, and normally reads blocks of text by having the magnifier track the text caret as she moves it through the content. However, as the developers considered theirs a non-interactive user agent, they left out the ability to do caret browsing. With luck, the screen enlarger will be able to access the application's DOM and determine the screen coordinates of each word, but it would certainly be easier if the application supported caret browsing.

Use case: The weather application that Imelda is running allows the user to select text with the mouse and automatically copies that text to the clipboard. However, the developers did not consider this "focus" or "activation", or even "selection" because the selection does not persist and the user can't perform their choice of actions on it. However, by this decision they are making functionality available to only one input modality, and users who rely on other modalities such as keyboard or speech recognition are denied full access. In this case, the developers should not have considered their application non-interactive, and instead implemented full focus and selection functionality.

Recommendation: The HTML5 spec should include wording that clarifies that user agents should not consider themselves non-interactive if they render content to the user on any system that can take input, and more specifically should not omit support for focus-related DOM APIs just because they do not expect to be taking input. Ideally it would include use cases similar to the above in order to help readers understand the issue.