It has been a wonderful experience working with accessible techniques this year. We developed a far more efficient and consistent workflow and learned a tremendous amount about accessible development as a result. Open Web accessibility continues to advance, as such it is a moving target we all strive to hit. In the spirit of better accessibility, we would like to share some insights into our thought processes; where we identified areas to carefully monitor, as well as some areas that require improvement.
Take a look at our accessible PDF version Accessibility Services — A Year In Review.
Generally, screen readers all work via wildly different techniques, and the support for standard inputs and controls varies as a result (think back to the infamous old browser wars of HTML4). We have found that while WAI-ARIA markup is fine for some, it’s best to err on the side of being semantically concise in lieu of bulk aria over tagging. Even the mainstream screen readers like JAWs seem to lack a breadth of user feedback and thus disallow basic controls like arrow keys outside of override controls. We focused on adhering to specifications and guidelines the industry has been championing. Our approach has been straightforward, build as simply as possible. Where conflicts occur, we provide intermediate user instruction via offscreen reading. On a side note, through the years during which we’ve worked interactive titles, the WindowEyes screen reader has fallen from grace and is little more than a blip on the usage matrix. Newer tools like ChromeVox and VoiceOver for Mac have effectively filled the voids.
The ZoomText tool, while useful to users with low-sight ability, has no impact on what is rendered by the OS/Browser combination, and thus in all our testing no failures have ever been reported as a result of its screen enhancing zoom. Food for thought when striving to curtail costs.
At the onset, this tool facilitated only the most basic interactions with accessible marked up content. We do suggest moving to the latest Dragon software as its support for accessible WAI-ARIA markup has been tremendously improved. Even the older version is a useful tool in the accessible user’s hands, with manual overrides where and when needed.
We focus on creating an accessible color palette, but when datasets become complex, the addition of toggle-able content to simplify the display for cognitive impairment has proven to be quite successful, not only in accessibility, but in content clarity and potential reusability of multiple datasets in one.
Contrast and Clarity
Much care was taken in making sure we used meaningful typographic spacing where possible. Of course the web is a different animal, being font agnostic for the most part and scalable as well. The responsive nature and volume of content made this tricky at times. We’d suggest moving accessibility talks into the initial storyboarding phases to save time by building only once, but also to help keep true to WCAG A and AA compliance — as when deadlines approach, too often the desire to do what’s fast overrides the desire to be compliant. We also recommend gearing content towards a narrative, thereby providing a means to separate a set of content to efficiently flow through in smaller chunks and potentially become more reusable.
Also, when color contrast of type on background scenarios occurred, we found that being flexible with font colors and use of text background scrim became a reasonable solution and was well received.
Image Art and Descriptions
We have a solid understanding/method for assessing images with color blindness criteria using filtering techniques and color contrast checkers. The approach taken with art is having it built with these considerations at the onset. By doing so, we negate having to redraw art to be compliant. Also, in scenarios where the art is in fact a data representation, we were able to utilize programmatic and filter settings to alter the art to be color blindness agnostic while maintaining the value of the dataset in question.
Given the small confines we work with in building interactives and the desire to really encompass as much learning as possible into each, space issues often arise. For example, in dataset charting, to be accessible one must provide a real time updated data table in the background for a screen reading user to hear. This area needs some further focus and planning as guidelines encourage the visual appearance of such tables upon user focus, i.e. the Tab key.
With a solid foundation into accessible techniques, we’ve found that Beta testing for accessibility versus every pass, resulted in equal success and conserved time. Also, it is advisable to streamline the testing platform base. Too often we see testing Matrices of 28–40 platforms including accessible testing. This equates to a tremendous inflation in development cost, coupled with redundant pass testing and results in more cost in testing than in development of basic interactives. Where possible, look to browser versions as opposed to OS versions, e.g. Are there differences between MacOSX 10.6 and 10.8? Sure. Are they both running the same version of Chrome? Yes.
Another solution to the testing matrix and development functionality cost woes is to build based on pre-tested interactive frameworks. This provides a low cost, high value solution with UI/UX consistency and predictability, while keeping the learning curve for new teams low and results stellar.