ARIA11 should reference role="region", and not role="application"

[carmacleod]

ARIA11 (latest) lists "application" as a landmark role, but it is no longer considered to be a landmark role.
This change was made 12-Nov-2015:

12-Nov-2015: Changed the superclass of application from landmark to structure

Also, ARIA11 should mention the generic role "region", which is one of the landmark roles.
Note that the HTML <section> element maps to region role by default.

Note also that the spec for region mentions that:

Authors must give each element with role region a brief label that describes the purpose of the content in the region.

AT do not expose region role or section element as a landmark unless it has a label, so the technique should require a label for using region role or section element as a landmark.

Please also add a link to this excellent browser extension for landmark navigation in the resources section.

[carmacleod]

Thanks for removing application role (and the application resources links) and adding the landmarks extension link, @alastc !

Do you plan to add role=region/section element in a separate PR? If not, then we need to reopen this issue, because that part is important, too. Let me know if you would prefer a new issue.

Also, I noticed a few more things in the ARIA11 Technique that aren't quite correct:

1. As of ARIA 1.2, AT do not expose the form role or form element as a landmark unless it has an accessible label, so any discussion or examples for form need to describe/show using either aria-label or (preferably) aria-labelledby.

2. In the following sentence:

   The search role typically goes on the form field or a div surrounding the search form.

   change "form field" to "form element":

   The search role typically goes on the form element or a div surrounding the search form.

3. The url to browser plugin and Enabling landmark-based keyboard navigation in Firefox are both old. Please update them both to use this newer url: https://developer.paciellogroup.com/blog/2017/05/improving-access-to-landmark-navigation/

Should this technique mention that certain HTML elements have implied landmark roles? Or is that a different kind of technique?

[alastc]

HI @carmacleod,

Sorry, I must have skipped the region bit, I've created a new PR: #1269

1. As of ARIA 1.2

I believe that's still in working draft? We generally prefer to reference recommendations. The only form example included in the technique is for a search role, and I don't think that is affected by the label requirement?

NB: The techniques are not trying to show all possible techniques, just enough so people can understand the intent. It is better to link to the appropriate spec rather than replicate them in the techniques.

2. In the following...

Updated.

3 . URLs...

Updated, with the first one going to the actual plugin page.

Should this technique mention that certain HTML elements have implied landmark roles?

That would probably be a new technique under HTML techniques, rather than ARIA.

[carmacleod]

Hi @alastc,

Thanks for the new PR! Looks good!

We generally prefer to reference recommendations.

Was pretty sure you'd say that. :) ARIA 1.2 will be moving to CR really soon, and we aren't planning to make any more changes (famous last words), however I understand about only referring to rec specs.

The only form example included in the technique is for a search role, and I don't think that is affected by the label requirement?

Correct - that's a search landmark, which does not require a label (unless there's more than one on a page, but that is already covered in the paragraph beginning with "There are cases when a particular landmark role could be used more than once on a page...").

The techniques are not trying to show all possible techniques, just enough so people can understand the intent.

Makes sense. I guess I just felt that if form was listed as one of the landmark roles, it probably needed a little "caveat clause" such as the one that you added for region:

, and needs a label to be included as a landmark for assistive technology.

(Hmmm... I wonder if that should say "an accessible label" so that it isn't confused with "a <label>"?).

I'll open an issue to add the clause for form after ARIA 1.2 goes rec (would you consider adding the clause after CR? PR? Just asking...). :)

Should this technique mention that certain HTML elements have implied landmark roles?

That would probably be a new technique under HTML techniques, rather than ARIA.

Oh right - thanks for the reminder. So, it looks like there's only one HTML technique for landmarks that I could find - yikes!
Grouping related links using the nav element

I've opened #1270 to connect that one up with the technique for adding a heading to the beginning of sections of content... which has an example of a list of links with an h2, and no mention of wrapping it all in a <nav>... hopefully, authors will look at the related techniques and see that nav's are one of the good ways to structure a page... :)

I'll open issues to add techniques for main, header, footer, aside, form and section. They will all have to link to each other (and to H97). Do you think those should all be in a single new technique? Maybe called "Using HTML structural elements to identify landmark regions of a page"? Or do you think it would be more consistent with other WCAG techniques to follow the example of H97 and create a separate technique for each of those 6 elements?

[carmacleod]

I'll open an issue to add the clause for form after ARIA 1.2 goes rec

Done. #1308

UPDATE: ARIA 1.2 reached W3C Candidate Recommendation status on March 2, 2021. So it is now official that elements with role="form" are required to have an accessible label before they are considered to be a landmark.

[fstrr]

@alastc

There are PRs in for #1270 and #1308, but do you have an opinion on whether we need a new HTML technique, essentially the HTML equivalent of ARIA 11, as Carolyn suggested? She didn't open an issue for that/those:

I'll open issues to add techniques for main, header, footer, aside, form and section. They will all have to link to each other (and to H97). Do you think those should all be in a single new technique? Maybe called "Using HTML structural elements to identify landmark regions of a page"?

[mbgower]

I'll open issues to add techniques for main, header, footer, aside, form and section. They will all have to link to each other (and to H97). Do you think those should all be in a single new technique? Maybe called "Using HTML structural elements to identify landmark regions of a page"? Or do you think it would be more consistent with other WCAG techniques to follow the example of H97 and create a separate technique for each of those 6 elements?

For the sake of expediency, I'd be more inclined to do just one technique. Unless there is some keyword search advantage? The fastest turnaround solution is what Carolyn originally suggested -- just shove a reference in the ARIA technique to HTML implicit equivalents. You can always take that out (or add a cross-reference) once the html technique is in place.

[fstrr]

Creating one technique was what I was thinking—there's no need to create separate pages for each HTML element. I'll start on that this week.

[fstrr]

Added an Issue 291 branch. Notes:

Updated ARIA11

Using ARIA landmarks to identify regions of a page. Updated content to:

1. remove outdated content (references to HTML 4.01, XHTML 1.0, etc.).
2. update links to out-of-date URLs, add https, etc.
3. update code examples to match HTML100, indent code, create hopefully slightly better examples.
4. add two new Tests and Expected Results
5. note: the content for the form role, added in ARIA11: Add clause about form role needing an accessible label #1308, is there but is slightly re-written.

Initial commit of new HTML100 Technique

Using HTML landmarks to identify regions of a page. This page creates an HTML version of the ARIA 11 document.