Re: ARIA use in HTML other than for accessibility.

While I appreciate your attempt to summarize this thread, I respectfully
disagree with a basic premise.

You seem to be conflating @role and ARIA.  WAI-ARIA, as you know, is a
large collection of states, properties, role *values*, and mappings to
specific implementations.  The purpose of this collection as a whole is
indeed to improve the accessibility of user interfaces.  @role is an
attribute.  The values of this attribute are evaluated and, when understood
by a UA, exposed to the Accessibility API for a platform.  Some WAI-ARIA
related values for role are defined in the WAI-ARIA 1.0 Recommendation.
Additional ones will be defined in 1.1.  Even more will be defined in
extension specifications. Over time UAs will learn about some / all of
these ARIA-related values and expose them.  The UA will also learn about
the related states and properties, their default values, inheritance rules,
etc.  That's what WAI-ARIA is all about.

I agree with you that there is no prohibition against using these values
for more general purposes.  I also agree that *ARIA* should only be added
to elements if the native semantics cannot do all of the job - in
particular state and property attributes.

However, again, you are conflating @role and ARIA.   I *disagree* that
@role is only about users and user experience.  It is about *consumers* of
the data.  Consumers include users, user agents, assistive technologies,
search engines, etc. @role and its values are uniquely positioned to
provide rich information to ALL of those consumers.  The only thing at all
in the way of this today is the (to me confusing) prohibition against using
@role with values that are the same as the default value for an element in
HTML (e.g., I cannot use role="heading" on an H1 element).  It forces
processors to have arcane knowledge of the ever changing rules of the
underlying markup language.  But that's a discussion for another day /
thread.

As to cogent arguments about why it should change... no one has proposed a
change.  Some people seem to be opposed to or surprised by the general use
of @role values.  Other people seem to be concerned about defining
additional ARIA-related @role values and adding them to the default
vocabulary.

I maintain that the "general use" ship has sailed.  The Role Attribute
Recommendation [1] defines the way in which @role is processed by
conforming RDFa processors.  You can argue that spec is not normatively
referenced by HTML 5, but the truth is that RDFa processors parse HTML 5
documents today using the rules of RDFa in HTML [2] as extended by the Role
Recommendation.  It is not "valid" to  extend the collection of role values
in HTML, but it is absolutely valid to use the values that are and will be
defined.  And those values will result in semantic information being made
available to consumers. Yay!

As to adding new values to the default vocabulary... Unfortunately, we have
no choice,.  Since HTML does not permit the use of vocabulary extensions as
defined in the Role Recommendation (e.g., myVocab:myRole), the only place
we can put new roles and have them validate is in the default vocabulary
space (if a user doesn't care about validation, then they can obviously use
then extension mechanism - it just works).  There might be syntactic
conventions we can adopt to help scope new values to avoid collisions, but
that is a detail.  As to specific, individual terms...  that's a discussion
that people can and will have.  But there will be more values.  They will
extend the vocabulary using the taxonomy rules defined in WAI-ARIA 1.0 /
1.1.  States/properties from "parent" role values will cascade into these
newly-defined roles. And that's *exactly* what was always intended.

You said "ARIA use in HTML makes sense when it results in concrete
improvements in the user experience."  Yes. Of course.  And the default
ARIA rules for various HTML elements mean that many of those improvements
come more-or-less for free to document and application authors.  With some
limited annotation a developer can improve it even more!  Complex
interfaces require complex annotations, but hopefully over time those will
less necessary as the underlying platform matures.

But here's a corollary:  Role use in HTML makes sense when it results in
concrete improvements in the consumer experience.  Any time I can inform a
consumer about the purpose of something in a way that is semantically
meaningful, that's a win.  Isn't it convenient that there is such
serendipity between these two concepts?  I use @role values to signal
information to the WAI-ARIA implementation in the UA and in the AT.  I
*also* can use @role values to tell the UA things that have nothing to do
with WAI-ARIA per se, but have everything to do with making information
about my content available.  @role="glossary", if the term "glossary" were
well defined, would tell a document processor where my glossary was.  An
aggregator could pull together all of the glossaries from all over the
place and make the terms and references available in ways you or I have not
yet imagined.  If that value *also* happens to be a WAI-ARIA value that is
known to the UA, and has a parent of "region" and various other attributes,
it could improve the user experience too!

To be clear, this use of role to convey semantic information was the basic
concept that ruled the (simple) design of the attribute from day 1. The
WAI-ARIA value taxonomy rules mean that there is a consistent way to extend
the default collection. The PFWG is working internally and with other
groups to develop these extensions.  When complete, they will only serve to
increase the benefits of using @role to inform consumers of the meaning of
content AND improve the user experience.  And that's good for *everyone*.


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

On Mon, May 4, 2015 at 3:47 AM, Steve Faulkner <faulkner.steve@gmail.com>
wrote:

> So far in this thread:
>
> Hopefully it is clearer now that the subject is a scoping issue for ARIA
> use in HTML. It is not about limiting the use of ARIA semantics added for
> UI accessibility purposes.
>
> A separate and worthwhile topic about baking event binding to UAs based on
> ARIA semantics has been raised.
>
> The paradigm in ARIA and in ARIA in HTML has always been only add ARIA if
> native semantics can't do the job of conveying UI information to users. If
> there is ARIA information in HTML making use of such information for more
> general purposes is not forbidden. But the addition of ARIA for purposes
> other than conveying missing UI information is actively discouraged.
>
> ARIA use in HTML makes sense when it results in concrete improvements in
> the user experience.
>
> I have not yet seen any cogent arguments why this should change. If there
> are, I welcome being disabused.
>
> --
>
> Regards
>
> SteveF
> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
>
> On 1 May 2015 at 10:10, Steve Faulkner <faulkner.steve@gmail.com> wrote:
>
>> Note: have ccd HTML a11y taskforce and PF, but please reply to HTML WG
>> list so a broader audience can read and contribute.
>>
>> Hi all,
>>
>> There is some discussion  going on currently about the uses of ARIA for
>> cases other than accessibility.
>>
>> My understanding in the context of HTML is that ARIA is to be used to
>> allow web developers to assign semantics to HTML content in order to make
>> it understandable to assistive technology users. And that it should only
>> be used when HTML features do not have this information baked in or
>> developers are building custom UI. Hence my formulation of the First
>> [informative] rule of ARIA [1] and the conformance requirements on ARIA in
>> HTML [4]
>>
>> The ARIA 1.1 spec appears to align with this view:
>>
>>> These semantics are designed to allow an author to properly convey user
>>> interface behaviors and structural information to assistive technologies in
>>> document-level markup.
>>>
>>
>>  So I was somewhat surprised to see a tweet [3] yesterday from Rich
>> Schwerdtfeger:
>>
>> ARIA is providing more semantics than host languages and it is growing.
>>> Developers and Designers would be foolish to limit its use to a11y.
>>>
>>
>>
>> I see problems arising from the use of ARIA in HTML for purposes other
>> than UI accessibility including:
>>
>> * Conflict with native HTML accessibility semantics
>> * Unnecessary cruft build up in the corpus of HTML documents due to its
>> extended use.
>> * Dilution of its relationship to accessibility APIs semantics and
>> increase in complexity of an already complex vocabulary.
>>
>> I would really think there is a need for this stuff to be more thoroughly
>> discussed, especially in relation to ARIA use in HTML as a host language.
>>
>> Review at your leasure, comment at will.
>>
>> [1] http://w3c.github.io/aria-in-html/#first-rule-of-aria-use
>> [2] http://rawgit.com/w3c/aria/master/aria/aria.html#h-abstract
>> [3] https://twitter.com/rschwer/status/593758137989013504
>> [4] http://www.w3.org/TR/html-aria/
>>
>>
>>
>> --
>>
>> Regards
>>
>> SteveF
>> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
>>
>
>


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