Re: Feedback from NVDA developer James Teh on ARIA landmarks

On 5 Nov 2008, at 10:07 AM, Aaron M Leventhal wrote:

>
> > On 11/5/2008 1:20 AM, James Teh wrote:
> > Hi all,
> >
> > It's probably too late to reconsider this now, but I'm curious  
> nevertheless:
> >

** summary:

I think this is a FAQ we will have to explain 'til the cows come home.

But I don't think it's something we should change.  The concepts of
the Universal Design or re-purposable interaction model are naturally
broader than how they look to the GUI thinker, the screen reader  
thinker,
etc.  Here is a case where we have an uncomfortably broad concept in
the semantics of roles where we include both widget roles and  
landmark roles.
But I think that we should address this at this point with explanation,
not spec change.

** details follow interleaved.

> > Why was it decided to specify ARIA landmarks using ARIA roles?  
> This does
> > not seem logical to me:
> > * The role of an element usually indicates its behaviour and how it
> > should be treated.

Usually in accessibility APIs.  Not usually in natural English.   
Actually,
the role that landmarks play in page structure is more like the  
natural-English
'role' than the euphemism-for-object-class that is the 'role' in the  
access
APIs.  Consider the roles of Participant, Staff Contact and Chair in  
a W3C
Working Group.  These are special or distinguished parts of the  
whole.  The
API roles are about how something acts independent of the context.   
Landmarks
are about how something acts, but with the context, not internally.   
So they
are quite different, but both about facilitating user interaction and  
both
about adding semantics to elements in the hypertext markup.

> > * Landmarks, on the other hand, provide structural information.  
> They do
> > not indicate the behaviour of an element.

Disagree.  Landmark behavior is a come-here method, but it's behavior.

What's different is that in the case of widgets, the page provides the
actions.  In the case of landmarks, it is the AT that provides the  
actions.
So from the standpoint of the AT they seem radically different.  But
in terms of the authors they are both cases of access-necessary- 
metadata.

> For example, whether an
> > element is a navigation landmark does not affect how it should be
> > handled by an AT; it is just a way of easily finding the element.

And the AT should handle it differently taking advantage of that help.

The AT should include top-tier landmark elements in a page summary on
entry, and in a table-of-navigation (DAISY term) synthesized navigation
tool at some times.

In the best of all possible worlds, the screen reader would handle
landmarks and headers in a combined page navigation interface.

>
> > * I think it would be more logical to specify landmarks in a  
> separate
> > attribute.

 From your perspective, definitely yes.

 From the least-common-denominator perspective of all stakeholders,  
maybe.

Given the history, I would suggest we not change this at this time.

> > * Landmarks are generally (always?) handled differently to normal  
> roles
> > by ATs. This in itself indicates that role is perhaps not the best
> > representation. See also this bug:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=459395
>
> Two reasons that I remember:
> 1. Historical. The role attribute wasn't invented by WAI-PF. It was  
> taken from XHTML, which used it originally only for landmarks. If  
> we wanted to keep them separate we probably would have needed to  
> have aria-widget= and put widget roles in there. If we try to say  
> that role shouldn't accept the XHTML landmark roles that means we'd  
> be trying to change someone else's spec, afaict. But, if enough  
> people agree, perhaps we can argue that things have changed and try  
> to make it happen.
> 2. There is the idea that something might effectively act as both a  
> landmark and a widget. For example, a menubar is definitely a  
> widget but the group considered it to be an effective landmark as  
> well.
> No one wanted to make authors put redundant info, e.g. <div  
> role="menubar" aria-landmark="menubar">
>
> That said, I do agree it would be nice to keep things separate.  
> There are several other ways of doing this that can be considered:
>
> 1. By putting a property on each role like "isLandmark".  Do you  
> have anything against this approach? The landmarks could thus be  
> exposed to NVDA separately from widget roles.

We presently distinguish landmark roles by what paragraph they are  
introduced in. (in the WAI-ARIA spec.)
Is this a property in the OWL ontology?  Could it be?  Why shouldn't  
it be?

As far as how these things are presented in the APIs, that is a  
separate decision from what attribute
is used in the hypertext markup, IMHO.

> 2. By using HTML element names for the landmark feature,  
> effectively removing landmark role usage from ARIA. IOW, use  
> <article>Blah</article> instead of role="article". Generally I hear  
> this belief from HTML 5 spec developers -- that role should not be  
> used for landmarks at all -use the new elements like <article>  
> instead. This was considered by PFWG but rejected, I think because  
> WAI-ARIA is a farther in on the process to becoming a W3C  
> recommendation.

It wasn't rejected that authors could use HTML5 elements; rather what  
was rejected was that we
fail to define the ARIA roles because the HTML5 elements are  
'available.'

Authors wishing to avail themselves of HTML5 elements can do so, and  
get implicit ARIA role
semantics (it says here -- work in progress, to follow WAI-ARIA spec  
proper in calendar time
in all likelihood).

> Pros: these elements haven't changed in years, are stable, and like  
> the rest of HTML 5 you can start using it. There also isn't any  
> major change required in browsers to use the new elements. Also, if  
> browsers implement native keystrokes or behavior related to these  
> elements it would be ok, whereas with ARIA we purposely prevent  
> that from affecting browser behavior -- it only describes what's  
> there.

I think it makes more sense to press on with the definition of  
specific (date picker) widgets and (article)
landmarks as elements in HTML5 together with browser-built-in  
behavior as appropriate.  More sense than
going back and splitting the @role usage into multiple attributes,  
each of which is a band-aid amendment
to the element semantics already.  We don't need too many attributes  
for different precise flavors
of band-aids.  Let that be in the attribute values.

> - Aaron

One of the things I find I have to explain over and over again is  
that "the people with
the answers see the world through a more fine-grained reticle -- in  
terms of a more
precise vocabulary of more specific concepts -- than do the people  
with the questions."

One instance of this is where Web consumers are the people with the  
questions and Web
authors are the people with the answsers.  But in this case the  
people with the answers
are the AT developers, and the people with the questions are the web
authors.  Their question could be stated "What do I have to do, to  
complete the information
you need to support adapted user interaction?

That question includes adapted navigation as well as widget  
operation.  So the landmarks
are in scope along with the widget roles; by that statement of the  
question.  So it makes
sense to give *the authors* one attribute to populate even though it  
seems to *the AT
programmers processing the attribute* that there are two classes of  
information being
given in that one attribute.

I think this is a FAQ, not a point justifying change to the spec.

Al

Received on Monday, 10 November 2008 18:19:17 UTC