RE: APG Landmark Design Pattern Update and Questions related to Banner and Contenting landmarks

Thanks Jon. There is a lot of useful information in this section, but my
concern is that it's lost in a lot of words and complexity.

 

For example the introductory content (before section 2.1) takes a lot of
words to describe something relatively simple.

 

I don't think we need to describe the audience specifically for this
section, or explain the "importance of logical, usable and accessible
layout". Those things are good to know, but they are not specific to ARIA
landmarks.

 

the term "table of contents" is misleading in this context. To most people a
ToC is a thing that appears at the start of a document. Whereas landmarks
can be used in that way in digital publishing, it is not the common use case
on the web.

 

Strictly speaking, landmarks do not make it possible to use JS to script
keyboard accessibility (or even make that any easier to accomplish). It's
useful to know that a landmark can be used as a hook, but I don't think it
needs so much attention in this context.

 

A simple introduction might be something like this:

 

"A landmark is a recognizeable feature of a web page that can be used for
navigation. Features like the header, footer, navigation and main content
area of a page can be identified using ARIA landmark roles. Assistive
technologies like screen readers provide keyboard shortcuts for navigating
between landmarks, and scripting can be used to provide keyboard navigation
within the web page itself."

 

In section 2.1 it says that "if HTML5 sectioning elements are used without
understanding the related landmark structure, assistive technology users
will most likely be confused and less efficient in accessing content". The
same is true if you use ARIA landmarks without understanding them properly.
This is the ARIA APG (not HTML), so suggest that we should focus on
describing how to create a robust landmark structure, then explain how ARIA
landmarks relate to HTML sectioning elements later on. This will make it
easier when other host languages introduce landmark mappings too.

 

Section 2.2 describes three steps and 17 points for identifying, labelling
and implimenting landmark roles. This gives the impression that landmarks
are complex. Using phrases like "perceivable areas", "semantic landmarks",
"peeling an onion", and introducing terms like "portlets", make it even
harder to understand what is actually a very simple task.

 

Section 2.2.2 indicates that a label must be provided for each landmark.
This is not the case and I do not think we should be recommending it either.
If there are multiple instances of the same landmark on the page, then a
label is definitely a good idea. Otherwise it just adds to the "verbosity".

 

Section 2.2.3 provides a list of the different landmark roles. This
information should be included much earlier on in the landmarks section –
not least because step 1 (identify logical structure) is much more difficult
when you don't know what landmarks are available to work with.

 

Developers are not generally known for their love of reading documentation.
They want to know what, when and how, then to get on with it. I think we can
make things much easier for our intended audience by radically simplifying
this section, removing much of the complexity (and complex language), and
restructuring it to tell a more logical narrative. For example:

 

2. Design patterns: Landmark roles.

//Short intro to landmarks.

2.1. Landmark roles.

//Descriptions of available landmark roles.

2.2. Landmark implimentation.

//Short intro (including role attrib).

2.2.1. Identify landmark regions.

- Identify regions of the page based on the available landmark roles. A
landmark region may contain other landmark regions.

(We could include a screenshot with landmark regions indicated perhaps).

 

Use the role attribute to assign the appropriate landmark to the containing
element for that region of the page. For example:

<div id="header" role="banner">…</div>

 

2.2.2. Labelling repeated landmark regions.

If a landmark is included more than once on a page, use one of the following
techniques to give it a label.

If the landmark region has a heading at the start, use aria-labellebdy to
make the heading the label for the landmark region. For example:

<div id="article" role="article" aria-labelledby="articleLabel">

<h2 id="articleLabel">Using ARIA landmark roles</h2>

…

</div>

 

If the landmark region does not have a heading at the start, use the
aria-label attribute to give the landmark region a label. For example:

<div id="siteNavigation" role="navigation" aria-label="Website">…</div>

<div id="pageNavigation" role="navigation" aria-label="Page">…</div>

 

Note: The label for a landmark region should not include the words
"landmark" or "region". Screen readers will automatically include that
information when they encounter a landmark on the page.

 

2.3. HTML5 and landmark roles.

//Description of relationship + links to HTML Aam.

 

Léonie.

 

 

From: Gunderson, Jon R [mailto:jongund@illinois.edu] 
Sent: 05 February 2016 21:45
To: Matt King <a11ythinker@gmail.com>; James Nurthen
<james.nurthen@oracle.com>; public-aria@w3.org
Subject: APG Landmark Design Pattern Update and Questions related to Banner
and Contenting landmarks

 

Here is the latest draft of the proposed ARIA Landmarks design patterns:

https://rawgit.com/jongund/aria/master/practices/aria-practices.html#aria_la
ndmark

 

We have some questions for the Monday call:

 

How and why do role=document and role=application affect the design patterns
for Banner and Contentinfo Landmarks.

See NOTEs in ARIA 1.1 Specs:

https://www.w3.org/TR/wai-aria-1.1/#banner

https://www.w3.org/TR/wai-aria-1.1/#contentinfo