Jewish Care Interact

Accessibility designed-in from the start

The best way to ensure a site will be good to use, is to test and iterate it with real users. For the JCi site that meant taking some pretty unusual steps to ensure that our user research and design process was in itself inclusive to all of our target users. Here’s how we involved older and disabled people in our user-centred site design process, to ensure that the JCi site is easy to use for everyone:

• Having in-person card sorting sessions with carers supporting a range of users with disability
• Creating an HTML prototype very early on, using web standards to ensure this could be accessed and user tested with a range of assistive technologies (AT)
• Conducting observational formative testing sessions with disabled users and their chosen AT systems, to see how the accessibility features not only work, but how user friendly they are
• Inclusion (with appropriate consideration and support) of users with cognitive and learning disabilities to help us simplify the interaction design. In our view, this has benefited all users in delivering a really simple UI even for complex areas of functionality such as the forum and the four care directories.

User testing with this wide range of users led to some interesting changes of tack. For instance we found that any attempt to overly abbreviate the main site sections made them confusing to navigate for some users. So we designed around that, adopting very long section names but with a more prominent initial word or two for easy reference e.g. ‘CARE WHERE you’re living or staying’. This eventual solution user tested extremely well, across the user base.

Developing with accessibility built-in

We then designed and coded the JCi site using the best web coding standards, delivering well beyond the WCAG specification in numerous ways. This often meant intercepting and improving on the code output by the CMS (in this case Drupal).

There are too many JCi accessibility features to list out (and some are very technical) but here are examples of what we delivered:

• Enhanced page elements with WAI-ARIA attributes to provide key information to assistive devices
• Added ‘skip to’ links where helpful for usability and in the context of the view port (e.g. some added for mobile views only)
• Explicit support for selected assistive technologies, for example the gesture-based VoiceOver on IOS and OSX (many allegedly “accessible” menus we’ve come across don’t in practice support these technologies, even though they are the mainstay of web access for many visually impaired users)
• Menus enhanced to be four-way keyboard navigable, i.e. with direction keys as well as (two-way) tab focus
• Accessible editorial, for instance with correctly ordered headings
• Form error messages – which appear directly before their relevant fields, as well an overarching error message at the top of the form. (The idea is that focus goes to this top error enabling AT users to re-navigate the form and correct the specific errors in situ).
• Excellent contrast ratios meeting or exceeding AAA, and to highlight key state changes (such as mouse-over and selected).