- Product Trial
To make Explorit Everywhere! more accessible, we have leveraged the Web Content Accessible Guidelines 2.0 (WCAG) accessibility guidelines provided by the W3C’s (World Wide Web Consortium—an international standards body to ensure the interoperability between web products. Accessibility refers to making sure that the design of products is usable for the widest range of abilities, such as for persons with different visual abilities, hearing abilities, or physical abilities.
Often the phrase “Section 508 compliance” is used in conjunction with ensuring accessibility, especially by government agencies. Section 508, which refers specifically to Section 508 of the Rehabilitation Act of 1973, which was amended in 1986, was passed to make sure that the Federal Government provides accessible electronic and information technologies to its employees—including computers, telecommunications, and so on, as well as access to web-based intranet and internet web pages and applications. More recently, though, the Assistive Technology Act of 1998 was passed to make sure that any state that receive Federal funding also adhere to some form of the Section 508 requirement.
WCAG 2.0 was written specifically for web content and web pages. It also leverages the same goals expressed in Section 508. In the WCAG 2.0, it has three priority levels of checkpoints where Priority 1 checkpoints must be met, Priority 2 should be satisfied, and Priority 3 may be addressed as part of compliance. In Explorit Everywhere!, we have confirmed that we meet most all of Priority 1 when applicable, many of Priority 2, and some of Priority 3 checkpoints. To better understand what changes we have made to meet these checkpoints, I am going to leverage WCAG 2.0’s four fundamental principles: Perceivable, Operable, Understandable, and Robust.
For the first principle, Perceivable, we have striven to make all components of the user interface evident on our web pages; that is, nothing is hidden. We have also used common iconography rather than inventing new ones that might not be understood so well. For each UI component, we have provided text alternatives, which includes both visual hover-overs on the pages and text alternatives for blind readers. And, based on UX feedback, we have rearranged the structure of the components so that the relationship between them makes more sense to the user or programmatically. Moreover, the meaning of our UI components are not meant to be contextual—that is, they are self-contained, nor are they dependent on color to convey meaning. We do use color contrasts to make the different components stand out more.
For our customer University of the Arts, London (UAL), being a specialized school for the arts, we have extended our application even further for their users by offering a selection of color themes for a user to select from, which is then saved to the user’s preferences (see Figure 1). These different options are designed specifically to make the interface more visually perceivable for different visual needs. UAL also asked that we add the ability to resize the text on the web page directly (as opposed to relying on the browser). These functions are available to any customer who wants to further extend their accessibility to offer more support.
For the Operable principle, we have focused on: keyboard accessibility, timing between functions, and navigable. The most basic operable support is to support keyboard access to all UI components, and to avoid any keyboard traps, that is, getting to a component that cannot be moved away from using the keyboard. Moreover, moving through the components does not require any specific timing for individual keystrokes. And, we have ensured that when initially landing on any page, there is a focused component for commencing keyboard navigation. When applicable, we offer more than one way to view results and to do certain functions since not all users do things the same way. One area for improvement that we intend to implement in the near future is the ability to jump pass entire blocks of content while keyboarding.
For the third principle, Understandable, we have ensured that Explorit Everywhere! is readable, predictable, and supportive of user involvement. While we believe we have made all the UI components readable and predictable, there is more work to do in making application errors more evident. For readability, we have reduced jargon, kept explanations simple, and avoided abbreviations. Predictability means not letting components randomly change in any way unless initiated by the user. This includes making sure that navigation and UI components are consistent across all functions. We have also expanded user preferences to allow users to save specific UI changes, and we intend to do offer more preferences to users in future releases.
The last principle, Robust, refers to supporting assistive technologies. Besides extending the keyboard accessibility, we have also reviewed our application in blind readers by making sure that our textual labels both as alt text and as hover-overs are accessible.
We believe that Explorit Everywhere! is even more perceivable, operable, understandable, and robust than ever!