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.
- 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.
Take a look at the various guidelines and best practices, including:
- Web Content Accessibility Guidelines
- Section 508 (US Government)
- Web Standards for the Government of Canada
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
- 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:
- Web Experience Toolkit (responsive, meets Government of Canada guidelines)
- jQuery UI (WCAG compliant)
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”
Another type of test is to use simulators or the actual tools that your users might use.
- WAVE Toolbar – view webpage as text-only, outline only, etc.
- Fangs: Screen reader emulator (firefox plugin)
- Mac VoiceOver
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.