Accessibility is a very important topic here at Open Concept, as our own Mike Gifford is a champion for accessibility and an organizer for the Drupal Group on Accessibility. As someone with a background in both health and information studies, I understand the necessity of designing a website to cater to the diverse users who need to access essential information. With limited knowledge of where Drupal is at in regards to accessibility, I set out to learn about the issues and new developments coming out of DrupalCon Portland.

Jesse Beach - a member of Drupal’s accessibility group - gave two presentations discussing accessibility. The focus was on improving Drupal’s aural UI - that is, improving code to work with screen readers, usually for those who are visually impaired.

As Jesse pointed out, accessibility is holistic interface design and development. Visual user interfaces are often highly designed and provide an experience for the user, whereas aural UI is rarely catered to. As it is, navigating a page without any visual cues tends to be quite difficult due to the lack of context attributed to the placement of objects on screen (especially when there are special features on the site, such as infinite scrolling - popular on sites such as Facebook and Twitter). Many navigational features and buttons are invisible to screen readers. Without any context or clues as to the website’s navigation, screen readers will not be able to provide an intuitive experience for the user - making it difficult for them to access the content they need.

Luckily, many efforts have been made to provide solutions to aural UI problems in Drupal 8, in the hopes of making it the most accessible version yet:

Backbone.js. Backbone.js is a javascript library with over 100 available extensions. It is currently being used to drive visual and aural views.

Drupal.Announce.The ‘announce’ method will pass strings to an ARIA-live region, so they can be read aloud by a screen reader (e.g. Drupal.announce(‘The application has been updated’)). Proper navigation should give the user context as they move throughout the site, and this method would give context to the content, so the user won't be lost in the navigation.

Drupal.TabbingManager.The group is currently working on a method which would help manage the sequence order when using ‘tab’ on the keyboard to navigate the page. This would allow one system to manage the tabbing throughout a page, rather than multiple ones. This would allow the tabbed navigation to be restricted to the elements within that specific task.

Eventually there will be an easy to implement aural presentation layer for Drupal sites, but in the meantime it is up to the developers and designers to consider accessibility and the diversity of users that will visit their site. The Drupal community has put forth a number of things ensuring that designers make accessibility a priority. This includes a statement, a pledge (#D8AX for Drupal 8), a checklist, as well as the currently existing guidelines for accessibility standards (WCAG 2.0 and ATAG 2.0). But, as pointed out by Jesse, there is no easy way to measure the support of these guidelines, so Drupal’s accessibility group is looking into having a full review of code admin pages, a full review of core templates, and a scoreboard of elements with a grade for each one (allowing metrics to measure and compare initiatives).

There are a number of tools that can be used to help assess the accessibility of a site (such as the WAVE toolbar for Firefox and markup validators). Since some developers may feel bogged down with the complexity of accessibility guidelines, Jesse suggests simply following the four principles of accessibility when designing a UI. The UI must be:

• Perceivable (the content is available to all the senses - sight, sound, and touch)
• Operable (action can be taken in the UI)
• Understandable (the content has context)
• Robust (all UIs are accessible and usable, especially be assistive technology)

Website users are diverse - and it’s important to have designers and developers who are able to think and behave the way users do. Aural testing and design is often not considered a priority, but there is a need for both designers and testers to branch out into non-visual site testing. In fact, there is a need for aural UI designers, keyboard UI designers (designing navigation using a keyboard, creating consistent hotkeys, etc), and mobile UI designers. Maybe once accessibility features become standard, aural navigation may no longer be an accessibility consideration, but a design one, creating new branches of design which may revolutionize the way websites are perceived and navigated.

In the meantime, Drupal developers should focus on giving the content of websites semantic meaning in order for it to make sense to all user interfaces. As Karen McGrane said in her keynote presentation - the way content is presented is constantly changing, so label and give context to your content in order for it to have meaning on each and every interface.  

How would your website handle a screen reader navigation? Is the navigation intuitive or just plain confusing? Remember to think about the many users who visit your site - and make accessibility a priority when building and maintaining it.

Click to view the entire summary of accessibility @ DrupalCon Portland 2013, and to view or contribute to the Drupal 8 Accessibility Support Goals.