Code4LibBC: Accessible Website Process Toolkit & Buy In

During the Code4LibBC breakout sessions, we had an ‘accessibility corner’. We talked about a lot of different things, but we covered two major topics: the process we might go through, and how to get buy in. While we have a google doc with notes from the breakout, hopefully this blog post organizes those notes and other thoughts into something a little more cohesive.

Getting Buy-In

  • efficiency of using styles vs. manual – If a change is required, you can change it once.
  • more consistent look
  • benefits for users
  • liability (Students can sue public institutions for lack of access)
  • make a specific person responsible
  • needs to come from both sides: bottom-up and top-down
  • create simple, easy to read guidelines for content creators e.g. Ryerson’s DMP Web Accessibility Guidelines

One success story: policy to get your stuff indexed into PubMed. Need for indexing is sufficient imperative for journals to solve problems, but also (mostly?) knocks accessibility on the head.

Website Process Toolkit

I don’t know what else to call it for the moment, but I hope that this becomes something that we can build on so that perhaps we move towards building a toolkit type resource for universal web design.

Guidelines

Take a look at the various guidelines and best practices, including:

Get Some Knowledgeable Partners & Resources

Consider contacting other departments within your institution or other organizations to see what help they can provide, such as:

  • Institutional disabilities services office
  • CNIB
  • CFB
  • look for a local organization or group

Put Yourself & Others in Your Users’ Shoes

User scenarios can help think about the different types of users that might access your website for particular purposes. They will also help you look at user workflow.

Empathy exercises can also help with putting yourself in users’ shoes. Some possible exercises:

  • Navigate with blindfold
  • Use computer without mouse
  • Try text-to-speech application
  • Colour blindness

Ask Your Users Again and Again

Early and through the process, you want to ask your users again and again what they think of your website at its current stage. Some standard user tests include:

  • card sort – to help determine the organization/structure of your website
  • 5 second test – using mockups, see if the user understands the purpose of your website, and where they might start to complete a specific task

In general, you don’t need a very large sample (unless you’re doing a research study). Often, just a few people will help you catch at least 80% of design issues.

Developing Your Website

To develop your website, you want to make it usual for as many people as possible, meaning across technologies (devices, browser, etc.). Some common methods to help include:

  • information architecture building
  • mobile first
  • responsive web design
  • content strategy

Look for toolkits or frameworks that have already been created and are accessible, such as:

Test Your Website

Obviously, you want to test your website to see how well they conform to guidelines.

  • HTML Codesniffer (bookmarklet) – for the web developer
  • Colour Contrast Checker (Firefox plugin)
  • “Cynthia Says”
  • A-Checker

Another type of test is to use simulators or the actual tools that your users might use.

Finally, do some user testing with real world users! Test with specific user tasks and try guerrilla testing to make it quick and short. Some recording somewhere that you might find useful:

Hopefully this is just a basis and beginning of something we can grow.