- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Mon, 10 Nov 2008 13:18:32 -0500
- To: W3C WAI-XTECH <wai-xtech@w3.org>
- Cc: jamie@jantrid.net, mick@kulgan.net
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