October 24, 2019 Accessibility Ecosystem: Critical Elements

“Let’s stop ‘tolerating’ or ‘accepting’ difference, as if we’re so much better for not being different in the first place. Instead, let’s celebrate difference, because in this world it takes a lot of guts to be different.”― Kate Bornstein

This article will talk about the critical elements of the accessibility ecosystem. Previous articles in this series are, Designing for Accessibility, Digital Accessibility, Topcoder and Accessibility, Accessibility Project LifeCycle, Topcoder-Planning for Accessibility, and Accessibility Platform for Topcoder. In this article, you will learn the critical elements of the accessibility ecosystem. We will look at key factors affecting accessibility such as page tabs, dialogs, calendar controls, mobile, multimedia, and multimedia control playback.

Every user and reader has equal rights to the content and information provided. When a disabled user accesses content for a specific task, that content needs to serve the accessibility requirements of the user. Disabilities can be related to hearing, vision, or movements of the body. The design of documents needs to factor in accessibility for all users. Microsoft and other software provide accessibility specific tools to create and fix documents so that they are accessible.

The software which publishes the content needs to include accessibility tags. Authors need to show the impact of the communication channel. The channel can be a picture, audio or a video.

Content gets published into and distributed from the aggregator platform. A fully accessible experience needs to be provided to all users from the aggregator platform. The publishers who provide the content will follow the guidelines for integrability with assistive technology tools. The required tags and labels for accessibility need to be handled during the data transfer and aggregation. The content needs to be tested for assistive tools by using accessibility guidelines.

The repositories which maintain the content need to ensure the accessibility requirements. The repository assets need to be catalogued and should be searchable by the user and the reader. Design of the content repository site is very important for low vision users and those with cognitive overload issues.

In the series, we have been looking at key factors such as menus, navigation, content, page structure, color, contrast, forms, images, keyboard accessibility, links, and  language. Now let us look at some other key factors.

The web pages need reflow without two dimensional scrolling. The reflow should not cause loss of content and content should be resizable. The user can override the text spacing and have the content available for the reader. Horizontal scrolling should be limited.

Regarding mobile content and accessibility, let us look at the available iPhone accessibility options for vision and speech:

The options for speech and interaction of iPhone accessibility are shown below:

The options for interaction and hearing of iPhone accessibility are shown below:

The iPhone accessibility options for media and learning are shown below:

For mobile content, content view in different orientation should not be restricted. Single point activation events should be ensured to be cancelled. The functionality should be operable using a single pointer. User interface components can be activated by motion and other mechanisms.

In multimedia, accessibility is considered by ensuring audible content is mentioned in the captions.Visual content is mentioned in the audio of multimedia content. Synchronized audio and video is provided with the media content and synchronized captions for video need to be provided.  Playback of media content needs to be controlled, and audio should not be played on load of an application. Media playback controls need to be mapped with shortcut keys.

The calendar controls need to be keyboard accessible.  Color should not be the only way to convey the selection of the calendar component. The data tables for calendar controls need to have header and data cells. The non-modal calendars need to be rendered inline with the activating controls. The focus needs to move according to activation and deactivation of the calendar controls.

Dialogs need to have proper structure. The keyboard focus needs to return from dialogs in the right way. Spawn dialogs from links should show information, non-modal dialogs need to be rendered inline with the controls which activate them, and dialogs need to be designed for closure by the keyboard, with a keyboard focus. Activated dialogs need to focus the move accordingly. A dialog needs to have the title defined. 

The multi column list view controls need to have the rows selectable using the keyboard. The headers should be sortable using the keys. Text alternatives need to be provided for sortable headers.

Content page tabs need to have a stated role. The menus need to be standalone, attached to the fields, and context specific. They should have keys mapped and programmatic focus needs to be provided. When the menus are closed, keyboard focus returns in the right way. The menus need to be openable from the keyboard. The sub menu items need to be provided with accessible keys and sub menu structure needs to be informed through help. The menus should be rendered inline with the activating controls.

This ends the accessibility series where we looked at the project lifecycle,  planning, design, Topcoder requirements, accessibility platforms and ecosystem.