Re: ARIA use in HTML other than for accessibility.

ARIA role values provide rich semantic information about any document or
application in which they are used.  To the extent that this information is
exposed, it improves the accessibility of the document or application for
everyone - meat or machine.

The Role Attribute recommendation [1] specifies the way in which an RDFa
processor may extract semantic information from the role attribute.  Such
processors are thus able to act as knowledge engines not just about the
*contents* of the document, but also about its structure. E.g., this is the
table of contents, this data is ancillary, this data is primary content,
this is the manifest, etc.

So yes, ARIA and @role provide MORE than just data for assistive
technologies.  This was the plan from it's inception more than 10 years ago
when Rich, Steven Pemberton, I, and many others started the work.

I understand that for whatever reason the HTML Working Group has restricted
the use of role to the values defined for ARIA.  We can debate that another
time if you like.  But the ARIA values are a meaningful collection, and as
the collection expands, and it will, the available semantic information
about documents and applications will also necessarily expand.  This can
ONLY be a good thing.

I appreciate that there are some in the HTML community who feel that the
use of values for @role should be constrained.  I (and the PFWG as far as I
know) disagree.  @role informs about the role of an element and its
contents.  The value(s) of that role can have many many consumers.  And
there can and should be a rich collection of role values so that those
semantics improve the use AND perception experience for ALL users.  @role
is indeed a 'curb cut'.  It is a game-changer for the way that user agents,
ATs, and knowledge engines perceive the structure of a document.  It would
be foolish and short-sighted to attempt to limit its use and thereby limit
that perception, in exactly the same way it would be foolish and
short-sighted to have said "closed captioning must only be made available
to people who are hard of hearing".

[1] http://www.w3.org/TR/role-attribute


P.S. As an aside, I feel strongly that it is a design error for HTML to
prohibit the use of @role on elements when the value in @role is the same
as the imlied value of @role for an element.  RDFa processors and search
engines should not be required to have this sort of arcane knowledge about
what they are parsing.  If I as a document author want to explicitly say
that an H2 element has a role of 'heading', I should be allowed to do
that.  Prohibiting it does not improve the user experience nor appreciably
ease the job of the user agent.  Instead, it merely decreases the ability
of generic knowledge engines to extract this meaningful information.
Moreover, as new roles are introduced and the built-in fallback mechanisms
of @role become more important, it will be even more critical that authors
be permitted to include this information in my content (e.g., <section
role="glossary region" id="my_glossary"> means this section is a glossary,
but if a user agent doesn't know what that is, fallback to region).  I
can't imagine a situation where I should be prohibited from including
explicit role settings in any context.


On Fri, May 1, 2015 at 10:37 AM, White, Jason J <jjwhite@ets.org> wrote:

>
> > 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.
>
> ________________________________
>
>


-- 
Shane McCarron
Managing Director, Applied Testing and Technology, Inc.