Spec Review/Structure

Under review:

• Common infrastructure

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

Section 2.2.1, Conformance Classes: 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.

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.

Greg Lowney will file a bug that encompasses this

Section 2.2.1, Conformance Classes: Visual user agents that support the suggested default rendering

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.

Kelly to file bug Bug 13489

Section 2.2.1, Conformance Classes: Conformance Checkers

(Note: no direct link to Conformance Checkers DT. Add ID?)

Oddly phrased sentence:

(This is only a "SHOULD" and not a "MUST" requirement because it has been proven to be impossible. [COMPUTABLE])

If the requirement is really impossible, the requirement shouldn't be in there at all. I think the author probably meant something like:

"This is only a SHOULD and not a MUST requirement because exhaustive and complete testing of all failure cases would be impossible."

Kelly to file bug Bug 13490

Section 2.2.1, Conformance Classes: Authoring tools and markup generators

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.

Add "accessible" to this list.

Kelly to file bug Bug 13418

2.2.3 Extensibility

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.

John to file bug: Bug 13430 - 2.2.3 Extensibility

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.

discuss

2.5.6 Colors

Note: CSS2 System Colors are not recognized.

Why not? System colors represent a major accessibility benefit to some users.

Janina to file bug noting that this overlaps with CSS WG issue Bug 13639

2.8.2.1 HTMLCollection

Only a, applet, area, embed, form, frame, frameset, iframe, img, and object elements can have a name for the purpose of this method; their name is given by the value of their name attribute.

Should input, select, textarea, and others be in that list? The name attribute is most frequently used on form elements. Same comment on the next section, "HTMLAllCollection."

discuss

2.8.2.3 HTMLFormControlsCollection

… an input element whose type attribute is in the Radio Button state and whose checkedness is true.

Editorial: The term "checkedness" is not a perfectly cromulent word. I believe "checked state" would be less awkward.

John to file bug Bug 13412 - Editorial change to 2.8.2.3 HTMLFormControlsCollection

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.

Greg to file bug for this with keyword a11ytf Bug 13442