In my first installment, I provided an overview about accessibility and the Web. I discussed what an accessible website is, and why it matters to Springbox and our clients. I also stressed how attainable an accessible site is, despite what you might think. Above all, the culture of digital inclusion is one that is always worth considering as part of a redesign or launch, no matter what your business’ legal obligations are.
Who is it for?
Designing for users with disabilities means bringing your whole team with you on a journey towards empathy and proactive user experience methods. You’ll be asking your agency or digital team to build for users with limitations in:
- Vision (blindness, low vision, color-blindness, seizure)
A website with a photo of a person might be absolutely meaningless to a sight-impaired user if there is no text to inform them of who the individual is. Simply adding code to denote who the photograph is of will help an individual using a screen reader to tab to that text and hear “Photograph of Mr. Blakely”.
But consider yourself too, consider an attempt to use your smart phone outdoors and the glare of the sun blinds you from seeing your screen adequately. Throughout our everyday interactions with digital interfaces any of us can become ‘disabled’ from time to time. It’s important to consider this, as well as the gradients of disability (low vision, not just blindness, etc.) when we begin to design our websites.
Who does it help?
When we say we are building a website to be accessible, it means a couple of things. First and foremost, it means following the standards set by the World Wide Web Consortium’s (W3C) WCAG 2.0 guidelines for accessible design. It also means building sites that tools can use to interpret content to users with disabilities.
Disabled users on an iPhone can use VoiceOver or Siri for help interacting with their device and understanding web page content, those who are vision impaired may use a screen reader to get audio assistance through their experiences without the use of a mouse, and a user who is hard of hearing might read transcripts to complete online courses or watch movies.
For more information on how users with varying degrees of access use tools to interact with accessible websites, read W3C’s collection of user stories.
WCAG 2.0 Principles (POUR) create websites that are:
Since the latest guidelines were created in 2008, there will be times when (particularly in mobile development) your team isn’t sure which path to take. In these instances, reviewing the POUR method and including accessibility in the quality assurance test plan from kick-off saves time and money.
But where to start?
If you’re planning to include accessibility as part of your site’s requirements from the beginning, good for you. That’s undoubtedly the easiest route. If you’ve already designed a site and are trying to work backwards towards compliance, you’ll spend more money than you need to and probably end up undoing some of your work depending on how close you are to compliance. For example, if your site plays sounds automatically, includes pop-ups, or non-compliant color schemes, you’ll need to start over. At the very least, you’ll have to go back through all your code and add transcripts, tags, and titles to ensure that all users can read and use the content on each and every page.
Your team might also read through the WCAG guidelines and determine which level of compliance is best /required for your project (A-AAA). You may also want to review your site to find out where you have the most work to do, creating a priority list of updates you want to accomplish over time. There are lots of resources on the web, and lots of tools your team can use to test as you build and deploy.
More questions? Want an accessibility review of your site? Contact us, we’re always happy to hear from people interested in broadening the scope of usability for their users.