W3C home > Mailing lists > Public > public-aria@w3.org > February 2016

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

From: Gunderson, Jon R <jongund@illinois.edu>
Date: Mon, 8 Feb 2016 17:35:59 +0000
To: "tink@tink.uk" <tink@tink.uk>, "'Matt King'" <a11ythinker@gmail.com>, "'James Nurthen'" <james.nurthen@oracle.com>, "public-aria@w3.org" <public-aria@w3.org>
Message-ID: <46739F12637CC94E82F75FF874E4A1473B8D096A@CITESMBX6.ad.uillinois.edu>
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>; '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

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_landmark<https://urldefense.proofpoint.com/v2/url?u=https-3A__rawgit.com_jongund_aria_master_practices_aria-2Dpractices.html-23aria-5Flandmark&d=BQMFAw&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=w0FeDItMtfVQ4CbDGLHD11wGr2CHZoZZhfT_jUnQ18I&s=p8uvuC4cdIC1DGp6Ix8gxXQdJfWcoSYey5vJ9IiM2Tg&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-2Daria-2D1.1_-23banner&d=BQMFAw&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=w0FeDItMtfVQ4CbDGLHD11wGr2CHZoZZhfT_jUnQ18I&s=H8jzXh4HrEPHUzFDYUPfEFg_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-2Daria-2D1.1_-23contentinfo&d=BQMFAw&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=w0FeDItMtfVQ4CbDGLHD11wGr2CHZoZZhfT_jUnQ18I&s=ONPOJkhd4WTkFik9-CQP3Ec2P-GPR4cwCI7XFj2QxBE&e=>
Received on Monday, 8 February 2016 17:37:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:20 UTC