CORE-AAM 1.1: Add conditional platform mappings for nameless regions

[joanmarie]

This is a spin-off from w3c/html-aria#64. To save people the trouble of clicking, what I stated there is:

@stevefaulkner: I'd like to triple check something to be sure we don't have unwanted side effects.

The ARIA 1.1 region role was modified and has several noteworthy characteristics that were not present in 1.0, namely:

• region subclasses the landmark role
• "Authors SHOULD limit use of the region role to sections containing content with a purpose that is not accurately described by one of the other landmark roles, such as main, complementary, or navigation."
• "Authors MUST give each element with role region a brief label that describes the purpose of the content in the region."

As a result, the Core AAM maps the region role unconditionally to the platform role associated with landmarks.

With the above in mind, your statement that

section always maps to region, it is only announced by AT when it has an accessible name.

Implies that every screen reader on every platform is going to have to sanity check landmarks just in case it's a section element that isn't named -- unless somebody changes something somewhere. Given what you've said in this issue, it seems to me that we should open an additional issue against the Core AAM with conditional platform mappings based on the presence or absence of a name. Do you concur, @stevefaulkner?

Steve hasn't replied yet. But I'm going to error on the side of caution and assume his answer will be agreement rather than calling me a fool. ;) If I'm wrong about that, we can close this issue. Otherwise, we need to make this change in the Core AAM because having to sanity check a valid, non-generic role "just in case" sucks. Doubly so when every screen reader might be stuck doing so.

[mcking65]

@joanmarie, I support the conditional mapping. As I understand it, that was the intent we had when making the ARIA 1.1 changes. At least that was my intent, and I am the one who raised the issue and wrote the spec changes.

I strongly agree that assistive technologies should not have to check to see if a region really is a landmark.

[matatk]

Forgive me if this is the wrong place to raise/contribute to this issue; it just seems very related to an issue I was planning to file on this repo.

Background info: my interest in this is that I am currently working on a WebExtension to expose landmarks on the page to people who do not have screen-readers, so that keyboard-only and visually-browsing users can navigate landmarks.

Anyway, my concerns are as follows.

1. If we consider landmark regions such as <form> (which maps to form) and <section> (which maps to region) it could be incredibly noisy for screen-reader (or other AT) users to navigate between the landmarks on the page. This is because things like <section> are often used to add apparent structure to the page, but do not have labels (e.g. via aria-labelledby or aria-label), and therefore do not add any extra useful signposting/landmark-style information. Further, there are often cases where web development frameworks will put a <form> around a whole page; that’d really screw up the landmarks hierarchy for a page if all <form>s — even the unlabelled ones — were counted as landmark regions.

   Therefore, as far as I am aware, most ATs will only report form or region landmark regions as landmarks if they have an accessible name, as provided via aria-labelledby or aria-label.

2. When I was researching what the ARIA spec actually has to say about this, the documentation for region is the only section of the spec about landmark regions that explicitly mentions what ATs should do (as opposed to UAs). It makes it very clear that a region must have a label, so it seems fine that ATs will ignore regions that are unlabelled (though, as you point out, I gather they currently have to perform this check themselves).

   However, none of the other landmark region parts of the spec (e.g. that for form mention whether ATs should report the landmark if it has a label or not. They only talk about UAs (which I take to mean browsers).

What am I proposing? There seem to be several options; either:

1. The simplest thing would be to add a clause to all of the different landmark regions’ specs to explain whether ATs would check if the region has an accessible name before exposing it to users (form and region would both need the check; others would not).

2. An alternative, which I gather you are proposing, is to change the spec to make it such that region landmarks won’t be exposed to ATs via the accessibility APIs unless they are labelled. I would urge you to consider forms in the same way.

In my case, the WebExtension I work on has to manually inspect the DOM anyway, but I think that either of the above changes to the spec would clarify things sufficiently for me to be able to implement the extension the same way as ATs would.

If you feel I should file this or any part of it as a separate issue, on a different document, please let me know.

[stevefaulkner]

@joanmarie
the history of this issue is: HTML5 section element maps to region role. This is implemented in browsers. So JAWS used to announce any section element as a region. This was annoying the hell out of screen reader users as the web developers sometimes use a section like it was a div resulting in there being multitudes of them in a web page. This lead to me adding a note, initally in the html spec and then in the HTML API spec.

Note: It is strongly recommended that user agents such as screen readers only convey the presence of, and provide navigation for section elements, when the section element has an accessible name.
https://w3c.github.io/html-aam/#el-section

JAWS implementers took note of feedback and followed the advice above (perhaps). Note also that JAWS decided to include article as a 'landmark' region. (but that is another story).

The desired outcome is that unecessary semantics are not announced, whatever way that is achieved I am happy with :-)

[klown]

@joanmarie for completeness, the Core-AAM should specify what the fallback AAPI role is. A simple approach is to use the native host semantic instead, i.e. the role associated with the element.

Similarly the ARIA spec should speak to this where it mandates a label for the region role. Here is a way to word it (the emphasized text is new):

"Authors MUST give each element with role region a brief label that describes the purpose of the content in the region. User agents MUST ignore the region role if authors do not provide a label".

Note that the fallback to native semantics doesn't work for the section element since it is mapped as a region, with the exception of UIA. In that case, an unlabelled section is treated as a div.

[mcking65]

@klown

I was hoping section would get treated like a div on all platforms UNLESS it has a label, which is when it would map to region.

[joanmarie]

I was hoping section would get treated like a div on all platforms UNLESS it has a label, which is when it would map to region.

That's what I'd like to see as well. (Edit: Assuming other platforms agree. But for my platform, it is what I'd like to see.)

[matatk]

I was hoping section would get treated like a div on all platforms UNLESS it has a label, which is when it would map to region.

From research I've been doing as an external but interested party: I think it's important to apply this to <form> (potential) landmarks as well, for the reasons mentioned above, namely:

1. There are instances in the wild of <form> elements wrapping whole pages [1,2,3] - these are not really valid landmarks, so considering them as such would add noise and confusion.
2. When a <form> is 'genuine': if it lacks a label, there's not really any useful landmark information there (it's easy enough to navigate to the form/first form control for most users anyway), so adding all unlabelled forms would add too much noise to the landmark navigation.

As far as I'm aware, this "only recognise it as a landmark if it's labelled" approach is used by assistive technologies when assessing <forms> right now, as well as <section> elements.

(I'd be happy to file a separate issue if that is better?)

---

[1] http://stackoverflow.com/questions/10122375/is-it-semantically-valid-to-wrap-all-pages-tags-inside-the-form-tag-asp-net
[2] http://stackoverflow.com/questions/3038217/why-does-asp-net-wrap-the-page-in-a-form
[3] http://webmasters.stackexchange.com/questions/45578/pages-wrapped-in-a-form-element-what-effect-would-this-have-on-seo-or-other-mac

[klown]

@mcking65, @joanmarie, I've opened w3c/html-aam#79 to modifiy the mapping of <section> as <div> if it is lacking a name.

[klown]

@matatk wrote:

(I'd be happy to file a separate issue if that is better?)

Yes, technically, this issue is about how the Core-AAM exposes role="region" and how that relates to the HTML-AAM mapping of the <section> element. Your comments on when the <form> element should be exposed as a landmark are related, however, that issue should be raised against the HTML-AAM, and likely an issue should be raised against the Core-AAM with respect to role="form".

(long time, no see, by the way).

[matatk]

Hi @klown, good to virtually bump into you :-). Thanks for the advice; I'll file an issue about <form> on https://github.com/w3c/html-aam and reference this one.

I have been looking to see if the Core AAM is another separate repo, along the lines of the HTML AAM, but I don't seem to see such a repo under the W3C GitHub account; suspect I am making a bit of a n00b error here, but if the Core AAM is another separate repo, could you point me to it? Thanks :-).

[matatk]

...n00b error indeed, sorry: of course this is where CORE-AAM issues go, I see :-). (I'm learning the relationships between the docs... slowly...)

[klown]

Modifications to core-aam:
ac1537e

Rawgit mappings for role='region'

[klown]

Closing as fixed. @joanmarie if you see a problem, feel free to re-open.