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.

Spec Review/Miscellaneous

From HTML accessibility task force Wiki
Jump to: navigation, search

User understandable rendering of Element Names and Roles

Migrated from UA wiki 26 July 2011

The addition of new semantic elements and roles within HTML5 implies that the elements must be understandable by users of assistive technologies. Authors can use a variety of techniques to supply human readable labels that name or describe the element. In cases where the UA does not identify an authored label, the UA is suggested to announce the element name. For example, the <details> element has an optional <summary> element that provides a label for or summary of the content of the detail. If the summary element is not used, the HTML5 specifications states:

The first summary element child of the element, if any, represents the summary or legend of the details. If there is no child summary element, the user agent should provide its own legend (e.g. "Details").

To support internationalization, semantic element names or roles, reported by the UA in lieu of an author specified replacement text, must be localized by the UA prior to any visual rendering and before passing to the Accessibility API.

Miscellaneous Comments on Specification (or applying Principle 3, Understandable)

Migrated from UA wiki 26 July 2011


checkedness is used 44 times in the HTML5 specification, but not defined. What is the definition of checkedness?

Global accessibility settings

Migrated from UA wiki 26 July 2011

Issue: Should the HTML5 spec define a standard, platform-independent way for content to query the user agent's accessibility settings, and by extension platform settings that are known to the user agent? Are there any equivalents today?

Use case: All major operating systems support a "high contrast" mode that tells software the user wants high contrast between foreground and background. Yev turns on this option, and in his browser he loads a web-based flow chart editor that displays all its document content in an HTML5 canvas element. The flow chart editor wants to detect when the user has high contrast mode turned on so it can adjust its graphical display appropriately. Because it's designed to run on any browser and any operating system, it needs a platform-independent means of querying this setting.

Use case: Kevin has turned on the "Show Extra Keyboard Help" option in the Windows Control Panel, which tells all software that he wants any and all options that enhance keyboard access to be automatically enabled. His web browser responds to this setting by, for example, always displaying the underlined access keys in menu and control labels. He would like web pages and web apps to also respond to this setting, even if they're creating custom controls.

Greg to file bug to provide global accessibility preference settings Bug 13619

Greg to file bug about privacy issues of global accessibility preference querying including inferring disability from e.g., custom style applied to element, detecting whether keyboard or mouse send an activate event, etc. Bug 13617

Discuss global accessibility issue in task force, along with the privacy issues such a setting would raise

Coordinate with Privacy WG on ways of addressing privacy implications of detecting AT use