October 10, 2019 Accessibility Platform for Topcoder
“Focus not on the differences of people with disabilities but the talent of the individual”― Neil Milliken
This article will talk about accessibility platform. Previous articles in this series include Designing for Accessibility , Digital Accessibility , Topcoder and Accessibility, Accessibility Project LifeCycle, and Topcoder-Planning for Accessibility . The reader will learn about the modules and components of the Topcoder website accessibility platform. In this article, we will look at key factors which affect accessibility such as frames, authoring tools and layout tables.
Early computers started with DOS operating systems, which were text based. The screen had characters and a cursor showed the position on the screen. For accessibility, the content was read from the screen and actions were intercepted before sent to the screen. The content could be modified to different zoom styles or alternative formats like voice.
Moving from DOS to other operating systems like Mac, Windows and Linux, interfaces have become more graphical. Images, videos and other content is handled in these operating systems. Accessibility technology needs to identify the content and present the information from the content. The graphical engine handles the API calls for handling text, images, formats, actions, and events from the interface. An off screen model can be developed from the API objects, calls, events and actions which can be used by screen readers and magnifiers. The off screen model is typically part of the screen readers, voice dictation software, and talking word processors with word prediction.
The off screen model needs to have the interface context, objects, actions and the operating system specific native methods. The role and state of the interface objects is also part of the model. The model is dependent on the operating system specific features and the accessibility techniques to handle those features as they evolve with the operating system. The model needs to have content alignment, white spacing, and formatting rules. Web browsers support accessibility APIs such as Microsoft Active Accessibility (MSAA), Microsoft UI Automation (UIA) and UI Automation Express (UIA).
Now let us look at accessibility technology platforms, which can help users who have problems with reading, writing, and scanning content from different content types and applications. The platform will have specific industry standards and criteria for accessibility. The best practices will be operating system specific and dependent on the content types. The concepts, auditing checklists, laws and methods are part of the accessibility technology platform. They can be used for different device types such as mobile, desktop, laptop and other devices.
The platform provides reports for the below:
- standard specific compliance
- violations for best practices
- accessibility status across the content
- compliance rates
- severity ratings
- noticeability ratings
- tractability ratings
- recommendations for issues
The issues and reports are presented based on the following guidelines:
- WCAG 2.0
- WCAG 2.1
- Section 508
The platform handles different content types, controls, input indicators, signals and alerts. The platform will support cognitive accessibility. Cognitive accessibility is related to memory issues, speed of processing information problems, organization and coordination issues.
In this series, we have been looking at different Topcoder pages and content types.
Let us look at the new Topcoder home page and the menu styles.
You can also look at the different menu styles and drop downs in the latest website.
You can browse the accessibility menu provided by clicking on the icon below:
There are a few issues highlighted from an accessibility point of view. The header issue is highlighted below. Headers typically identify page introduction and navigation. They surround the web site, page name, logo, top navigation, and other content. Headers provide page semantics and navigation. To fix this issue, the header should surround and define the page header content.
Below is an issue related to missing document language. The language of the webpage needs to be identified. This helps screen readers to read the content in the specific language and provide automatic translation of content. To fix this, the document language needs to be set using <html lang> attribute.
So far in this series, we have looked at key factors such as menus, navigation, content, page structure, color, contrast, forms, images, keyboard accessibility, links, and language. Now let us look at authoring tools. Authoring tools need to have features to produce content which follows WCAG 2 guidelines. The tools need to have capabilities for exporting to PDF and other UA conformant documents. During format conversion, the tools need to retain the key information from the content. Accessibility specific templates for these tools need to follow certain guidelines and standards.
The website will have frames and iframes in the page design. These frames need to have the text set right, the titles need to be meaningful for the frames, the sizing of the frames should be absolute and the frames need to have source specific markups. Other website controls like layout tables need to be accessible conformant. The layout tables need to have absolute sizing and not show the structural markup. The use needs to be specified and these tables should be linearized.
In the next part of the series, we will look at other areas of accessibility such as data tables, charts, graphs, trees and outlines, page tabs, dialogs, calendar controls, animations, dynamic content, multimedia, multimedia control playback, and typography.