PF/ARIA/BestPractices/Layout
3.4 Logical Layout Semantics
- 3.4.1 Regions and XHTML Role Landmarks
- 3.4.2 Structural Roles and Navigation impact
- 3.4.3 Implicit Nesting
- 3.4.3.1 header levels versus nesting levels
- 3.4.3.2 `owns` repairs nesting
- 3.4.4 Groups and Headings
- 3.4.5 Grouping vs. Regions
This section of the Best Practices document is intended to assist you in conveying a logical, usable, and accessible layout to an assistive technology or adaptive system designed to modify the visual layout to meet the users needs. It is important to start by defining a few terms:
Role:
A role is an indicator of type. An object's role is the class of objects of which it is a member. This semantic association allows tools to present and support interaction with the object in a manner that is consistent with user expectations about other objects of that type. Roles are element types and should not change with time or user actions. Changing the role on an element from its initial value will confuse an assistive technology, and, ultimately, the user. Platform-specific accessibility APIs, to which the roles are mapped by the browser, do not provide a vehicle to notify the assistive technology of a role type changing. If the old element type is replaced by a new one, the corresponding element and its subtree should be removed from the document, and a new one inserted containing the new role type.
Region
The term region defines a group of elements which, together, form a large perceivable section of a document instance, which the author intends to be included in a summary of page features, such as a "Table of Contents" or "Summary of Regions".
XML Namespace identifier:
The roles taxonomy uses the XML Namespace identifier. An XML namespace is identified by a URI reference. Element and attribute names may also be placed in an XML namespace. URI references, however, can contain characters not allowed in names, and are often inconveniently long, so expanded names are not used directly to name elements and attributes in XML documents. Instead qualified names are used. A qualified name is a name subject to namespace interpretation, while element and attribute names appear as qualified names. Syntactically, they are either prefixed names or unprefixed names. An attribute-based declaration syntax is provided to bind prefixes to namespace names and to bind a default namespace that applies to unprefixed element names; these declarations are scoped by the elements on which they appear so that different bindings may apply in different parts of a document. Processors MUST recognize and act on these declarations and prefixes.
Example: Declaration of a wairole using XML Namespacing:
xmlns:wairole="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#"
This is part of the ARIA Best Practices document. There may be discussion {todo: edit link} about this page; please use the discussion page to address issues and add only content to this page.
3.4.1 Regions and XHTML Role Landmarks
One of the deficiencies for (X)HTML for disabled users has been they usability of keyboard navigation. Users, dependent on a keyboard for navigation, have been forced to tab everywhere in the document as the only document elements which are keyboard accessible are form and anchor elements. This has forced developers to make most everything a link to make it a keyboard accessible and to get to each link you have to tab to it. With the advent of portals and other content aggregation means web pages are divided into visible regions and there has been no vehicle to get to them other than perhaps to do things such as:
- Create a skip link at the top of the page to the main content
- Make the head of each perceivable region (search bar, stock quote, TV Listing, etc.) an
tag
There are three problems with this approach:
- Both force the user interface to change to support accessibility
- In the case of using
to mark your regions, this is not consistent across web sites
- The semantics are limited to main content and a section
ARIA provides two vehicles to mark sections of your document:
Follow these steps to assign to mark each logical section:
Step 1: Identify the large perceivable regions of your web page
Make a note of each logical region of your document (think of it like a portal). Think about the user wanting to navigate to these logical "portlets" on your web page. Write down a description of what you believe each section to be.
Step 2: Look at the standard xhtml role landmarks to see which one best fits each region of your page
If possible it is best to use these as landmarks. They will be common landmarks which your assistive technology will become very familiar with on every site. Furthermore, your browser may assign key sequences to move focus to these sections as they can set on every site. Furthermore, navigation to these landmarks is device independent. A personal digital assistant (PDA) could assign a device key to get to them in your document. These are the common xhtml landmarks:
- banner
A banner is usually defined as the advertisement at the top of a web page. The banner content typically contains the site or company logo and other key advertisements for the site.
- contentinfo
This is information about the content on the page. For example, footnotes, copyrights, links to privacy statements, etc. would belong here.
- definition
The contents of the associated element represent a definition (e.g., of a term or concept). If there is a dfn element within the contents (as defined in [XHTMLMOD]), then that represents the term being defined.
- main
This defines the main content of a document.
- navigation
This is the navigation bar on a web document. This is typically a list of links to other pages on the site or other areas of the same document.
- note
The content is parenthetic or ancillary to the main content of the resource.
- search
This is the search section of a web document. This is typically a form used to submit search requests about the site or a more general Internet wide search service.
- secondary
This is any unique section of the document. In the case of a portal, this may include but not be limited to: show times; current weather; or stocks to watch.
- seealso
Indicates that the element contains content that is related to the main content of the page.
Assign the appropriate landmark to each of your web page regions and choose a short title for each of these regions.
Step 3: For the landmarks that just won't fit use the region or select region ARIA roles
If you are a rebel and just have to define your own region outside the common landmarks then you can. ARIA has some region roles which you may also use as landmarks:
Assign the region role to those regions and choose a short title to go with it.
Step 4: Set the landmarks in your web page
Typically each section will be something innocuous like a
<div role="main" title="Top News Story"> <div role="secondary" title="weather">
For ARIA regions here are some examples:
<div role="wairole:log" title="chat log"> <div role="wairole:region" title="Game Statistics">
When you use the wairole namespace, remember to define the wairole namespace prefix in the header as described above.
ARIA's Structural Roles include:
- columnheader
- description
- directory
- document
- grid
- gridcell
- group
- heading
- img
- list
- listitem
- presentation
- row
- rowheader
- section
- sectionhead
- separator
- treegrid
3.4.2.1 Use of Document vs. Application and Screen Reader Browse Mode
While ARIA is designed to address many disabilities, this section is best described in terms of screen reader use. In desktop applications, screen readers typically treat widgets as discrete entities, reading and interacting with each widget one at a time. The user moves the point of focus from widget to widget using tab/shift tab, mnemonics, or accelerators, keyboard commands which are usually provided by the application or the operating system. We refer to this mode of interaction as "application mode."
When viewing web content however, screen readers often gather information about all the widgets in an area and present them in a document-like view which the user navigates using keyboard commands provided and controlled by the screen reader. Think of this mode as a virtual environment that presents web content in a way that makes it convenient for adaptive technology users to navigate and read. This is sometimes called browse mode, or virtual mode. We refer to this as "document mode."
Because screen readers often provide document mode navigation support using single key mnemonics on the alpha-numeric keyboard, they may provide a third mode, called "forms mode," used to interact with form controls that are encountered in document mode. Behavior in forms mode is similar to that of application mode. The key feature of forms mode is that it can be toggled with document mode to make it easy to both interact with a specific widget, and read virtualized content of which the widget is a part. Since, as described above, a screen readers perception of an area as either a document or an application greatly influences how the user reads and interacts with it, ARIA provides content authors a way to indicate whether their pages should be viewed as applications or documents by assistive technologies.
To set document or application mode follow these steps:
Step 1: Set the Application Role
After you have divided your web page into regions through the use of role landmarks and custom regions, you must make a decision: Is your web page an application or not? If it is, set the role of application on the body tag as follows:
<body role="wairole:application">
Special Considerations:
If your page has only a few isolated widgets, like pop-up calendars located on a web page, it is not necessary to expressly set the role of application on the body. Screen readers, based on widget roles, should be able to provide access to these widgets without recognizing the entire page as an application.
Also, browsers make use of a feature called the contenteditable attribute, which will be incorporated into HTML 5. Contenteditable allows an author to turn the browser section into a rich text editor, similar to a word processor. Any section which has contenteditable set to "true" is considered a widget.
If the body element has been given the role of application, please follow step 2. Otherwise, the web page is considered a document, and no further action is required in this regard.
Step 2: Set the Document Role
Look at the regions/landmarks you have defined and determine which ones should be browsed as a document or navigated as an application. For each region which should be browsed, embed a div element within it with the role of document as follows:
Now, when a screen reader encounters this region, it will be displayed in document mode.
3.4.2.2 Use of the presentation vs. CSS
Presentational Roles
An element whose role is defined as presentation does not need to be mapped to the accessibility API. The presentation role's intended use is to mark an element which is used to change the look of the page, such as a TABLE used to control layout, but which does not have all the functional, interactive, or structural relevance implied by the element type for which the presentation role is defined.
A user agent may remove all structural aspects of the element being repurposed. For example, a table marked as presentation would remove the table, td, th, tr and any other child elements of TABLE, while preserving the individual text elements within it. Because the user agent knows to ignore the structural aspects implied in a TABLE, no harm is done by using a table for layout.
The following is an example for using the ARIA presentation role to convey layout:
<table role="wairole:presentation"> <tr> <td>see</td><td>spot</td><td>run</td> </tr> <tr> <td>over</td><td>the</td><td>lazy coder</td> </tr> </table>
3.4.2.3 Use of Remaining Structural Roles
Editor's Note: Content pending
3.4.3 Implicit Nesting
3.4.3.1 Header Levels versus Nesting Levels
The heading role value signifies a heading for a section of the document instance. Use of the heading role indicates that a specific object serves as a header. A heading should be referenced with the labelledby property of the section for which it serves as a header. If you have a heading and there is no element containing the content that it heads, wrap the content in a <div> bearing this labelledby attribute. If headings are organized into a logical outline, the level property can be used to indicate the nesting level.
3.4.3.2 Owns Repairs Nesting
Assistive technology briefs users on the context where they are. When they arrive at a new page, a page summary may be given. When they move into a new context, some of the labeling from elements containing the new focus or reading location may be read out, to give context to the details to be read next.
The syntactic structure of a page provides the default nesting of contexts. If a paragraph is nested in a <div> or table cell, it is assumed that labels for the <div> or headers for the table cell are pertinent to what is in the paragraph. On the other hand, it is not possible to always flow the logical structure one-to-one into the parse structure. The owns relationship is provided to annotate logical nesting where the logical child is not a syntactic descendant of the logical parent.
A conspicuous use case for this capability is the construction of a treegrid structure, building on the basic structure of an HTML <table>. Here some rows are logically within the scope or nested under some other rows. The <table> syntax does not allow nesting of rows in rows. So in this case owns relationships are used flowing from the rows that identify general topics to the rows dealing with sub-topics of that topic.
3.4.4 Groups and Headings
3.4.5 Grouping versus Regions
What Is A Group?
A group is a section of user interface objects which would not be included in a page summary or table of contents by an assistive technology. Sections of user interface objects that should be included in a page summary or table of contents should be identified as a region.
Authors should use a role of group to form logical collections of items in a widget such as a:
- row in a grid;
- children in a tree widget forming a collection of siblings in a hierarchy; or
- a collection of items having the same container in a directory
Proper handling of group by assistive technologies, therefore, is determined by the context in which it is provided. Group members that are outside the DOM subtree of the group need to have explicit relationships assigned for them in order to participate in the group. Groups may also be nested.
If an author believes that a section is significant enough in terms of the entire document instance, then the author should assign the section a role of region or a standard XHTML Role landmark.
What Is A Region?
The term region defines a group of elements that together form a large perceivable section of a document instance, which the author feels should be included in a summary of page features, such as a "Table of Contents" or "Summary of Regions".
When defining a region for a section of a document, authors should consider using standard document landmark roles defined by the XHTML Roles Module. This makes it possible for user agents and assistive technologies to treat roles as standard navigation landmarks. If the definition of these regions is inadequate, authors should use the ARIA region role and provide the appropriate title text.