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

John,

 

I think the main reason some of us are not very hip on the table of contents
analogy is that a table of contents is usually thought of as a comprehensive
list of contents, sometimes down to a pretty low level. This can give people
the impression that every section of page, perhaps every h2, h3, and even
h4, should be wrapped in some kind of landmark region. This wouldn’t be a
good general practice and can lead to having way too many landmark sections.
And, in some cases, some places where a landmark section would be very
useful to the end user may not end up with one because it doesn’t fit the
TOC model in people’s heads.

 

If a web page is strictly a document and nothing else, like the ARIA spec
for example, then the TOC model is not horrible. But, such pages are very
rare.

 

Matt

 

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

 

Leone,

 

Ann Abbot and Teresa are also working on the edits.

 

I agree there maybe some better language to make information clearer.

 

I like the steps since I think it helps at least some people have a starting
point for understanding landmarks and they are much more streamline than the
steps in APG 1.0

 

I am not sure why using the analogy of a “Table of Contents” is getting so
much resistance, since it is something that most people can understand and
help people to understand what landmarks can do.   I think where the analogy
breaks down is that it is not useful when people get into sub sections, so
maybe there is a better way to describe the analogy as a “high level table
of contents of the content regions on the page”.

 

Thanks for your feedback,

Jon

 

 

From: Léonie Watson [mailto:tink@tink.uk] 
Sent: Saturday, February 06, 2016 8:40 AM
To: Gunderson, Jon R <jongund@illinois.edu <mailto:jongund@illinois.edu> >;
'Matt King' <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> >; 'James
Nurthen' <james.nurthen@oracle.com <mailto:james.nurthen@oracle.com> >;
public-aria@w3.org <mailto:public-aria@w3.org> 
Subject: 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 <mailto:a11ythinker@gmail.com> >; James
Nurthen <james.nurthen@oracle.com <mailto:james.nurthen@oracle.com> >;
public-aria@w3.org <mailto: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
<https://urldefense.proofpoint.com/v2/url?u=https-3A__rawgit.com_jongund_ari
a_master_practices_aria-2Dpractices.html-23aria-5Flandmark&d=BQMFAw&c=8hUWFZ
cy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=w0FeDItMtfV
Q4CbDGLHD11wGr2CHZoZZhfT_jUnQ18I&s=p8uvuC4cdIC1DGp6Ix8gxXQdJfWcoSYey5vJ9IiM2
Tg&e=> 

 

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://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_wai-2Dar
ia-2D1.1_-23banner&d=BQMFAw&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5
jSLVS8bjZtAodDOhat7yAI&m=w0FeDItMtfVQ4CbDGLHD11wGr2CHZoZZhfT_jUnQ18I&s=H8jzX
h4HrEPHUzFDYUPfEFg_A1mE8DNjSutUf_CYuXA&e=> 

https://www.w3.org/TR/wai-aria-1.1/#contentinfo
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_wai-2Dar
ia-2D1.1_-23contentinfo&d=BQMFAw&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInst
fW3L5jSLVS8bjZtAodDOhat7yAI&m=w0FeDItMtfVQ4CbDGLHD11wGr2CHZoZZhfT_jUnQ18I&s=
ONPOJkhd4WTkFik9-CQP3Ec2P-GPR4cwCI7XFj2QxBE&e=>