Navigation by ARIA landmark

[nvaccessAuto]

Reported by jteh on 2008-10-09 17:13
The ARIA role attribute can be used to define structural "landmarks" on a web page. NVDA should provide the ability to navigate to any defined landmarks.

The current list of landmarks is: "article", "banner", "complementary", "contentinfo", "definition",  "main", "note", "navigation", "region", "search", "status"
We may also wish to consider adding: "log", "menubar", "grid", "tree" and "treegrid" since, even though they are also widgets, there tends to be only 1 on a page and they are of major importance. They are so important that they are effectively both a widget and a landmark.
Blocking #195

[nvaccessAuto]

Comment 1 by jteh on 2008-10-09 17:28

• Test case
• The xml-roles object attribute contains the ARIA role string, so this can be used to search for landmarks.
  • Unfortunately, xml-roles contains the entire role string, which might include multiple roles. This poses a problem for our virtual buffer search code, which can only handle full string matches on each property.
• What key should we use for navigating to landmarks?
• Should other keys be provided for specific landmarks?

[nvaccessAuto]

Comment 2 by lpintes (in reply to comment 1) on 2008-10-10 07:16

• What key should we use for navigating to landmarks?
• Should other keys be provided for specific landmarks?

Crazy idea: we could define a new modifier, for example space. So, space+key would be navigation key for finding next object of particular type, and analogously space+shift+key would find previous object.
This could be useful not only in this context, but for example in the following:

• In any window, it would be possible to quickly jump to object of particular type (Button, Checkbox, etc.)
• In programs like HTML editor, it would be possible to use similar navigation keys like in virtual buffers, so navigation would be possible.
• What about to add this type of navigation to Microsoft Word?

I don't know how difficult this would be, or if this is even possible.

[nvaccessAuto]

Comment 3 by jteh (in reply to comment 2) on 2008-10-11 12:04
Replying to lpintes:

Crazy idea: we could define a new modifier, for example space. So, space+key would be navigation key for finding next object of particular type, and analogously space+shift+key would find previous object.

This is an interesting idea. However, implementing a modifier such as space is not a good idea because space should always act as it does normally. Also, implementing another modifier is not trivial. Aside from this, this still means memorising a lot of keys. IF you are still interested in this idea, it would be best discussed in another ticket.

For the initial implementation of landmarks, I've come to the conclusion that having one key to move to any type of landmark would be best. Enhancements to this can then be extended once the initial implementation is complete.

[nvaccessAuto]

Comment 4 by jteh on 2008-10-11 12:05
MozillaBug:459395 suggests the implementation of a landmarks object attribute, which would allow ATs to distinguish between normal and landmark roles easily.

[nvaccessAuto]

Comment 5 by benjaminhawkeslewis (in reply to comment 3) on 2008-10-11 12:35
Replying to jteh:

IF you are still interested in this idea, it would be best discussed in another ticket.

I've created a ticket for navigation to regions of particular types, as this seems fundamental to how landmark roles are expected to improve the end-user experience:

http://www.nvda-project.org/ticket/195

Note I've avoiding putting it in terms of ARIA landmarks alone, as from an end-user's perspective it shouldn't make any difference how the semantics are derived (e.g. via HTML4, ARIA landmarks, HTML5 elements, heuristics, or whatever).

[nvaccessAuto]

Comment by jteh on 2008-10-12 00:30
(In #195) Would it be correct to call all of these regions "landmarks" (as opposed to "ARIA landmarks")? Accessibility APIs should have a concept of "landmarks"; see MozillaBug:459395. This will allow the various forms of markup to be exposed simply as landmarks, thus unifying the interface to ATs.

Note that this functionality can (and probably should) only be available in our virtual buffers. Web applications (i.e. where document browsing concepts are not used at all) should act as desktop applications and provide similar ways to navigate.

What do you mean by contextualising if in a particular widget? Can you provide an example?

[nvaccessAuto]

Comment 7 by jteh on 2009-07-08 02:44
Changes:
Milestone changed from None to 0.7

[nvaccessAuto]

Comment 8 by jteh on 2009-07-08 10:43
MozillaBug:459395 won't be implemented. Therefore, we must use xml-roles.

I implemented searching for a single word in a string of words in nvVBufLib main rev 136. We will use this to search for landmarks.

[nvaccessAuto]

Comment 9 by jteh on 2009-07-09 12:02
Implemented in r3047.

I used the smaller list of roles provided by the ARIA spec (minus application) rather than the bigger list provided here. More roles can be added later if desired.

I'll open other tickets for issues such as providing a landmarks list.
Changes:
State: closed

[nvaccessAuto]

Comment 10 by vtsaran on 2009-07-14 18:18
It doesn't seem that NVDA recognizes the landmark role of status. Any reason for this?

[nvaccessAuto]

Comment 11 by jteh on 2009-07-14 23:19
Unless I'm misreading, according to the ARIA 1.0 spec, status is not a landmark. I can follow that logic. Status is documented as:
A container whose content is advisory information for the user but is not important enough to justify an alert. Also see alert.
I tend to think of landmarks as important, major sections of a page, where status is more of a small chunk of information. Also, apparently, status is supposed to be a form of live region.

All that said, if you still want status as a landmark, it's very easy to add.