Assistive tech SHOULD provide landmark navigation... user agents MAY

[carmacleod]

Resolves #350.

Issue #350 noted some discrepancies in the normative language across all of the various landmark roles.
This PR ensures that the wording is uniform, including making sure there is a normative statement for both AT and UA.

I was given permission by the ARIA WG to go part-way (SHOULD instead of MUST) towards my earlier comment:
> if I could, I'd spec it so that user agents MUST enable users to quickly navigate to landmark roles...

So this PR basically uses statements similar to the following for each of the landmark roles:
> Assistive technologies SHOULD enable users to quickly navigate to landmarks.
> User agents SHOULD enable users to quickly navigate to elements whose implicit role is a landmark.

---

Preview | Diff

[carmacleod]

Broken link to "landmark roles" in region role definition. Will fix...

[mcking65]

I could be convinced to support as is ... but would prefer that changes that align with my suggestion were made.

[carmacleod]

@mcking65

Why do we need the word "mainstream"?

I'm happy to take out the word "mainstream". I wondered about it myself, but left it in to keep the number of changes to a minimum, and because I saw it in several other places in the spec. I've opened issue #1321 to review the other occurrences.

I also don't understand why a user agent would limit the capability to elements with an implicit role. I have a hard time believing there would be a significant difference in implementation difficulty.

I don't think it's about implementation difficulty. It's actually a philosophical issue... the user agents do not want to provide any behavior that relies solely on ARIA markup. I'm quite sure that, as you say, there wouldn't be any significant difference in implementation difficulty for implicit vs. explicit landmarks, but, to quote a UA dev, "It's a slippery slope. If we provide behavior for this ARIA role, then people will ask why we don't provide behavior for this other ARIA role".

That said, there's nothing stopping the ARIA spec from saying that user agents SHOULD enable users to navigate to all landmarks regardless of ARIA or implicit markup... so I've changed this PR to use the wording that you provided above. I prefer your wording because it's simpler, and because it's what I really wanted to say in the first place:

User agents and assistive technologies SHOULD enable users to quickly navigate to elements with role [landmark role].

[cookiecrook]

Removing my review request, since as a Member Rep I'm not in a position to endorse a precedence change this significant. I stopped short of rejecting the review, because I can relate to some extent.

As I mentioned in this morning's ARIA WG meeting, it's possible various stakeholders will take issue with ARIA requiring mainstream user interface changes like this. Playing devil's advocate on a couple of the potential objections below.

1. Lack of Precedence. I don't think there is any other precedent for this in ARIA. As @carmacleod pointed out, ARIA §1.3 User Agent Support states "The WAI-ARIA specification neither requires nor forbids user agents from enhancing native presentation and interaction behaviors on the basis of WAI-ARIA markup." So this would be a pretty major precedence change IMO. You might get pushback based on the slippery slope argument. The same section of the spec gives a non-binding suggestion, "Mainstream user agents might expose WAI-ARIA navigational landmarks (for example, as a dialog box or through a keyboard command) with the intention to facilitate navigation for all users" but to my knowledge the ARIA spec has never before included any mainstream UI as an RFC requirement.

2. Ambiguity. The prior language (~"treat as landmarks") was also vague, but was widely interpreted as "expose landmarks to the platform Accessibility APIs", which all user agents now do. The new language states that UAs should (RFC-2119 SHOULD) "enable users to quickly navigate to" landmarks. It doesn't state how to do so or how to test the implementations, presumably because ARIA has never before defined this level of mainstream interaction detail. As such, it seems more like a wishful advocacy/evangelism change, and I'm not convinced a Rec-Track spec is the right place to do that...

3. Priority. I don't think a sufficient case has been made for why mainstream users need this and why they'd need it now. Sure, we can speculate that landmark navigation might be nice for power keyboard users, but wouldn't a browser extension or a keyboard-driven AT solve that need? As an example, some sighted users use VoiceOver (with speech on or off), and therefore have access to landmark navigation; why does it have to be in the browser? The WG would need to make a better case that this benefits all users and that a significant amount of them would use it.

In either case, HTML or WICG may be the better place to discuss new behaviors for mainstream user agents. A polyfill or browser extension might be a good way to prototype the interaction you're hoping to achieve.

In the case that this stays in ARIA and the edit is merged into the 1.3 branch, I assume the editors agree on the following:

• It would have to be removed before CR unless there were two implementation commitments and tests available.
• It would have to be removed before PR unless there were two completed implementations.

[mcking65]

@cookiecrook wrote:

In the case that this stays in ARIA and the edit is merged into the 1.3 branch, I assume the editors agree on the following:

• It would have to be removed before CR unless there were two implementation commitments and tests available.
• It would have to be removed before PR unless there were two completed implementations.

I thought only MUST statements require implementations and tests?

Regardless, I do find your arguments for why the spec might not (MAY NOT) be the most appropriate mechanism for advocating for browser support to be thought provoking, close to compelling. However, I do see distinct lines between browser support for landmark navigation and other types of browser support that would muddy the contract with authors. I don't see any risk of distorting the author/browser contract with this type of requirement. I'm assuming that contract is the top concern when it comes to ARIA influencing browser behavior.

[smhigley]

(official Microsoft hat on, the following is the response from Edge)

Microsoft recognizes the value that native-browser-supported landmark navigation would have; however we are hesitant to see such a value-add feature promoted to a "should" requirement for all user agents to support. We would prefer the specification maintain a "may" status [RFC2119]. We have not observed a dramatic demand for this feature and note that a variety of browser extensions currently provide this capability for users who would like to have this feature today.

[carmacleod]

Ok, I've changed the language to essentially say the following for each landmark role:

Assistive technologies SHOULD enable users to quickly navigate to elements with role [landmark].
User agents SHOULD treat elements with the role of [landmark] as navigational landmarks.
User agents MAY enable users to quickly navigate to elements with role [landmark].

This is basically what is currently in the spec, except that the first 2 sentences are now consistent across landmark roles, and the 3rd sentence is new. The abstract landmark role only includes sentences 1 and 3.

The only other changes are a slight rewording of the existing sentence in main role about skip links, removal of the word "Mainstream" from landmark and region roles, and fixing a broken link to the list of landmark roles in region.

@cookiecrook @smhigley
Please re-review, or ask your people to re-review. Thanks!

@aleventhal
I think it's important for you to review this one, please. :)

[cookiecrook]

Fine to submit as-is (thanks) but you might also consider leaving the role-specific text the same, and instead add these two new normative statements one time, in the Landmarks section.

[carmacleod]

Thanks, @cookiecrook !
For the record, none of the normative statements are new. :)
Two of them were already in the landmark and region sections.
The third was in all the rest.
It just felt really inconsistent.
Plus it seemed odd that most of the landmark roles mentioned UA, but not AT.