Re: ARIA use in HTML other than for accessibility.

> On May 1, 2015, at 06:50, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
>
> Where my head is at on this is that people should look at ARIA semantics to drive the user experience. At its core ARIA defines semantics for UI (structural, state, and properties). At IBM we have already begun to use it to drive the look  of user experiences. When we have meetings with IBM designers we are now having semantic discussions for which we can both talk on the same level and build user experiences that are meaningful. If we start with ARIA semantics we can use it to drive the style of the UI and reducing the amount of JavaScript. This is becoming increasingly important for mobile.
>
> We are also crossing the line between what is for accessibility and what is not. ARIA is becoming a curb cut for user experiences. We are looking at digital semantics for digital books, drawings, etc. If we are successful with ARIA semantics for books we can use it to drive UIs like every user being able to say: "Go to the glossary.”
To add a glossary role, one would need to implement it in a user agent, then (in most cases) add it to system-level APIs, possibly at multiple levels, then support it in assistive technologies and localize the name. This is all extraneous to the visual interface, which has to be achieved through whatever scripting, CSS and event handlers are needed in the application.

There have been ARIA extensibility proposals that would reduce this workload by allowing the author to specify a localized name and possibly map the new role to a more generic equivalent. However, the effort required is still considerable.

Let’s step back from ARIA and HTML and think instead about Web components. Suppose I’m defining three custom elements for my application: glossary-reference (to appear in the body of the document), glossary (a container element) and glossary-entry (for an individual definition, possibly with child elements). The question for the evolution of Web technologies as means of application development is this: how can constructing my “glossary” Web components, for example, be made as straightforward as possible so that I can write my user interface features and ensure that the semantics are available to all of the tools that can process them?

This is a much broader question than ARIA extensibility, as it requires thinking about the entire authoring experience. What we want is for me to be able to write my Web components, for example the glossary elements exemplified above, so that they can be reused and plugged into applications and documents as appropriate. I should only have to specify the semantics of my custom elements in one place. The accessibility should be built into each Web component. It should be easy to support diverse input devices (pointing device, touch input, keyboard input, speech input) as well as a variety of outputs - graphical displays of different sizes and resolutions, speech, braille, haptic/tactile for graphical material, etc.

I strongly favor a model in which user agents provide extensible mechanisms that allow application authors to create flexible and accessible Web components to express custom semantics and implement custom behaviors.


________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________

Received on Friday, 1 May 2015 15:37:48 UTC