Re: ARIA use in HTML other than for accessibility.

On Fri, May 1, 2015 at 6:12 PM, Michael[tm] Smith <mike@w3.org> wrote:

> [trimming Cc]
>
> Shane McCarron <shane@aptest.com>, 2015-05-01 12:46 -0500:
> > Archived-At: <
> http://www.w3.org/mid/CAOk_reEp6_2CwBO0Y8Bz4-CwBvxZyF0NN38kT09B-PDttqeZ5Q@mail.gmail.com
> >
> > ...
> > The Role Attribute recommendation [1] specifies the way in which an RDFa
> > processor may extract semantic information from the role attribute.
>
> The Role Attribute spec isn’t relevant to HTML, since the HTML spec doesn’t
> normatively reference it, nor even indirectly reference it.
>
> Instead, the HTML spec defines a native HTML `role` attribute that aligns
> with the requirements in the ARIA 1.0 spec at
> http://www.w3.org/TR/wai-aria/host_languages#host_general_role
>
> That section is the only part of the ARIA 1.0 spec related to the `role`
> attribute which the HTML spec normatively references. (And so, since that
> section doesn’t itself reference the Role Attribute spec, the Role
> Attribute spec isn’t even indirectly relevant to HTML.)
>
> > 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.
>
> While that may have been the plan way back when, that’s not the scope that
> HTML constrains use of the actual HTML `role` attribute to. The HTML spec
> makes reference to the `role` attribute strictly in the context of its as-
> implemented purpose in exposing information about a document:
>
> > To enable assistive technology products to expose a more fine-grained
> > interface than is otherwise possible with HTML elements and attributes, a
> > set of annotations for assistive technology products can be specified
> > (the ARIA role and aria-* attributes). [ARIA]
> http://www.w3.org/TR/html/dom.html#aria-role-attribute


Yes.  I am aware that the HTML 5 Recommendation hamstrung our efforts to
incorporate extensibility into @role.  It's not like I wasn't around at the
time.


>
>
> > I understand that for whatever reason the HTML Working Group has
> restricted
> > the use of role to the values defined for ARIA.
>
> The reason is that to do otherwise and instead implement an open-ended
> `role` attribute along the hypothetical lines in the Role Attribute spec
> would violate design principles that have guided HTML over its history (I
> mean HTML as implemented and shipped in actual Web UAs—in contrast to, say,
> XHTML2 or XHTML Modularization or whatever) and especially in HTML as
> (re)architected over the last 10 years, and so because to do otherwise
> would be inconsistent with the rest of HTML and break with many precedents.
>

Actually, I think this is misleading.  I appreciate that the HTML Working
Group has decided that extensibility of the collection of elements and
attributes needs to be tightly controlled.  I disagree with it, but I
understand it.  However, the collection of VALUES for attributes is not
something that needs to be constrained in the same way.  The ARIA
definition of @role that you cite requires that user agents fall back to a
value that they recognize in exactly the same way that the object element
(used to) require that user agents cascade until they find a media type
they support.  This is entirely consistent with the sort of forward
evolution / backward compatibility principles that have guided all open
standards development.


>
> > 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.
>
> Actually I think it can be a quite bad and harmful thing—especially if it’s
> the case—as it seems to be now with, e.g., the 30+ DPUB properties that
> there’s an effort going on to push into the `role` attribute—that the
> collection is getting expanded with proposed values that are either largely
> unnecessary and without any demonstrated relevance to actual user needs in
> the real world, or redundant with existing ARIA role values to the point
> that they are essentially just aliases.
>

Now that's just silly.  These people are domain experts representing the
largest publishers in the world.  The EPub standards work has been going on
for ages. The work on semantic richness of digital publications and
ensuring are accessible is critical to that industry.  Textbooks.
Interactive lessons.  On-line testing.  I have worked in and around
educational computing since 1980.  There is no industry more invested in
ensuring their content is available to everyone.  Who are you, I, or the
HTML working group to say they are wrong about what their constituents need?


> > I appreciate that there are some in the HTML community who feel that the
> > use of values for @role should be constrained.
>
> It’s not just “some in the HTML community”—it’s the as-defined HTML
> language which is making those constraints, as documented in the HTML spec.
>

I know.  And I also know it was a vocal few who made this happen, and that
the PFWG rolled over and agreed because they had little choice.  That
doesn't make it right.  It just makes it the status quo.

>
> ...
> > 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".
>
> That’s not at all a reasonable analogy in this case.
>
>
Why not?  Seriously.  Just think about the name of the attribute.  "role".
We chose that for a reason.  The values of that attribute define the role
of the element and its contents in the context of the document.  That
information is useful all over the place.  How arrogant of is to tell the
rest of the world "don't eat the fruit from this tree".  That NEVER ends
well.



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