Accessibility
Office for Civil Rights (OCR)
I worked on a team that was able to get a university’s website cleared by the Office for Civil Rights. What started as a 25 thousand page website, was audited and whittled down to 15 thousand pages, all made compliant and switched over to the redesign that was occurring simultaneously.
Taught Classes
The university’s web system was decentralized, so it was comprised of over 400 individual editors (usually people who were roped into doing it - not tech professionals), all of whom had to go through two training classes. One class was how to use the CMS (Content Management System) in general, the other was how to keep your pages compliant. I was one of the teachers of the course, I also did one-on-ones for people who couldn’t make the regular class or needed to start right away.
Tools
One of the issues with accessibility tools is that they don’t all see the same issues, so you have to use a combo of them. These are a few of the tools I use while checking for accessibility errors.
WAVE/WebAim
The cheapest tool to use when trying to make a website compliant is WAVE. You can either put the link straight in the website, or add the extension to your chrome browser.
This tool will show you different classes of errors as well as structural elements.
It's a quick way to see errors that are relatively easy to fix.
Powermapper
Powermapper is a little more complicated. I've only used the demo version, but it finds a lot. It catches a lot of backend errors (ones that front end will advise IT about), but it also grabs TOO much. Some of the issues it grabs are really non-issues, so you have to take it all with a grain of salt.
My team also moved from using Powermapper to Level Access during the overhaul.
Level Access
Level access is the only paid-for accessibility software I've used. If you think Powermapper pulls up too much, just wait until you meet Level Access! I think the best part about this program is that you can run multiple pages and sections at once (if you have your parameters set correctly), and have it exported to an Excel spreadsheet. But if your dream is to get it to say your website is 100% perfect and give you a gold star…it's not going to happen for you. There are just some errors you're never going to be able to fix, so you just have to ignore them and deal with the important things.
Screenreaders/JAWS/NVDA
I've mostly used the free version of JAWS. Screenreaders are very helpful for testing your webpages because that's how a blind person (or any number of other disabilities) will navigate your page. I've mostly used it to make sure a page can be tabbed through (only using a keyboard.) Other than that I mostly just keep in mind the functions of a screenreader when I'm teaching the rules of compliance or I'm making judgment calls on complicated accessibility issues.
ARIA coding language
ARIA coding language is a language that speaks to screenreaders. You use it to label structures and elements in your pages so the screenreader knows what everything is and its function within the page. I had to learn how to use this to get a lot of things compliant, as well as learn the limitations of it.
Info about ARIA:
https://www.w3.org/TR/html-aria/
ARIA Label example (featured in image):
https://www.w3schools.com/access...
Basic Accessibility Information
WCAG
Web Content Accessibility Guidelines (WCAG) - basically these are the rules for what accessibility looks like on the internet. The internet is essentially a living document, so things are always changing, so WCAG does the same and updates periodically (this is where the 2.0, 2.1, etc comes from.)
More info on WCAG:
https://www.w3.org/WAI/sta...
Alt (Alternative) Text
Alt text is on the HTML side and indicates to a screenreader what is in an image. This can also be helpful for SEO (Search Engine Optimization.)
It is a critical error to skip it completely, but it's also a bad error to do it poorly.
You want to describe your image descriptively but concisely (there's a character limit.) There are also rules. You don't want to use the word "photo" because the screenreader has already indicated to the user that this is a photo. There are other similar buzzwords like "infographic" that aren't allowed as well.
Headings
The basic way content on a page should be structured is using headings. You always want to start with an H1 (heading #1.) This is critical because it tells the screenreader where the beginning of a page is. It's also important for google hierarchy. Having an H1 (much less a descriptive and unique H1) tells google that this page is important.
Another crucial issue related to headings is "skipped headings." Headings should be treated like a staircase, you can go up and down - but don't skip over steps. (Example: H1, H2,H3,H2,H3,H4)
Tables
Tables are generally a huge pain. They are very delicate to make responsive and compliant. Almost no system can make them responsive without manually editing them.
With standard tables the code isn't too complicated, but when you get into tables with multiple headers…it gets a little funky.
More info on tables:
https://www.w3.org/WAI/tut...