Slide3-7 Web Page Structures

People with cognitive and learning disabilities can more easily find and prioritize content on the page.

Keyboard users can browse pages and their sections more efficiently. Otherwise, users have to press the tab key multiple times to navigate through all links in each section.

People using software that only shows the main content of a web page, such as people with cognitive disabilities, will receive better results if the page structure is correctly marked up.

People with visual impairments, low vision and blind, have cues that provide orientation on the page and in the content.

Mobile web users often have access to a reader mode that will only show the main content of the page if it is correctly marked up.

People using certain browser plugins can use landmark roles to jump to specific sections on a page.

There are additional benefits to a good, accessible page structure, beyond those experienced by people with disabilities. As an example, search engines can use the data to better index the content of a page.

A modern browser creates two user interface object models to communicate content. The two models can be compared to a book. A book can be produced in paper format with the cover representing the home page and the pages the content. A book can also be produced in audible format, which depends upon the quality of the reader. Also, a book can be produced in digital format, which can be accessed by mobile readers or braille displays.
The Document Object Model (DOM) to convey the visual aspects of the web page, and the Accessibility Tree Model (ATM) to convey the audio/tactile nonvisual aspects of the web page.
The user interface uses three components to create a good user experience.

1. Device: For the visual model this could be a computer screen display, and for the nonvisual model this could be a screen reader and braille display.
2. Interface: for the visual model this means colour, pixel density, fonts, images and spacial orientation. For the nonvisual model this means pronunciation, descriptions, tone/inflection and content structure.
3. Experience: For the visual and nonvisual model this means language, attractiveness and clarity. The DOM is built from HTML and CSS. The ATM is built from HTML and ARIA (Role, State, Properties). JavaScript enhances the user experience.

Every page should have its own, unique TITLE element.

People who use magnifiers to view a web site find skip links useful. Often a person using a magnifier will only see a small part of the screen. Often it is not obvious where the content is from this small part of the screen.

The web page should be divided into perceivable block areas, which contain semantically associated information called Regions. Each region can be divided into logical subregions as needed. For users with cognitive and learning disabilities the landmark information could be used to expand and collapse these regions of your page to aid in simplifying the user experience by allowing the user to manage the amount of information processed at any one time.

It is important that headings are nested properly in order to convey the structure and hierarchy of the page. It is important not to skip heading levels (Example, a H4 should not follow an H2). Screen reader users scan a web page using a variety of features, such as links, form controls and headings. Most screen readers can pull out the headings, and present them to the screen reader user in hierarchical order. This can provide a great amount of information to users and help them navigate through the page effectively.

Structural labels should be used to help describe different components of the page to screen reader users. Providing hidden structural labels assists screen reader users to identify lists of links and access the information provided via the hierarchy. The inclusion of structural labels is an effective and relatively simple solution to the significant problem some screen reader users have in identifying the different elements on a page.

Breadcrumbs are an additional navigation tool that assists both people with and without disabilities to navigate through a large or complex site. It is especially important where other navigation mechanisms, such as the Back button, have been broken. Breadcrumbs should provide the hierarchical position not the chronological pathway in the site. That is, even if a user came to a particular part of the site through inline links, the breadcrumbs should provide the navigational pathway to that page.

The Application Program interface handles the communications between the operating system and the user computer device. Assistive technologies can make standard method calls to the operating system to get information about the objects on the screen.

1. A web developer writes some HTML code.
2. That HTML code is retrieved and parsed by a user agent browser.
3. The user browser creates and maintains an Accessibility Tree Document Object Model representation with only HTML information that is relevant to the assistive technology user agent.
4. The Accessibility Tree is exposed via the operating system accessibility interface handler.
5. The assistive technology user agent then interacts with the interface handler to retrieve information about the web page.
6. The assistive technology screen reader reads the content to the end user via a refreshable braille display and/or synthesized speech output.
7. Screen Reader video demonstrations

Keyboard users get to a widget by tabbing, but once they land on the widget they switch to using arrows keys to navigate, and the enter or space key to activate a control. Otherwise, they would have to tab through every link to get past the widget. By setting the element attribute tabindex=0, an element will be placed in the tab order of the document, So when the user tabs to the element the browser will stop and set focus to that element. ARIA provides mechanisms for non-focusable elements to receive focus through the tabindex property.
Accessibility Web Page Structures

It is important to test the keyboard interface without a mouse.

1. Implement the widget with a JavaScript keyboard event handler.
2. Test with a keyboard and screen reader.
3. Press Tab key to move focus to the widget, Shift+Tab key to move focus backward from the widget.
4. Open the widget with Enter or Spacebar key and place focus on the first child element within it.
5. Press Arrow keys to move focus one step in each direction.
6. Press Home and End key to move to the start and end of the control range.
7. Press Page Up and Down to move focus in larger chunks of child elements.
8. Press Escape key to close the widget without performing any action.
9. Web Accessibility Initiative (WAI): Learn More About Basic Page structures