Category Archives:

How to Get Started to Make Your Website WCAG 2.1 Compliant

More and more places are requiring accessibility compliance. If you are in the United States, Section 508 defers to WCAG to set it’s standards for compliance, in lieu of any rules made directly by our government. 

Well, luckily for me, my graphic design professors did wedge in some accessibility aspects into my web design classes. Sure, it was not exhaustive, but it was enough to inspire further independent studies on the subject. I am often shocked how I encounter professional developers who ignore accessibility. I guess they stay on-scope, as most clients don’t even know to ask for accessibility of a website. To me, taking the time to put in a simple alt tag attribute is essential; not only does it help with screen-readers, but it helps with SEO. So, if you don’t have any accessible features in your website, and maybe even if you paid a lot of money for the website, don’t feel so bad, but do get on the move to fix the problem now that you are aware of the issue.

What is WCAG Accessibility?

Before mice, keyboard-only UIs were the thing, so it is odd how this standard has fallen off the grid. Of course, keyboard-only access to a website is only one aspect of your testing, you’d think it would just be standard. If you decide to meet WCAG compliance, you’ll find you have to test other aspects as well, in order to truly optimize the web experience for all.

Accessibility is making sure your website makes sense for users of all types:

  • average vision
  • low vision
  • no vision (blind)
  • average motor control
  • motor control issues, including no motor control
  • cognitive issues

You might find that your user-interfaces are challenging to you as an average bodied and average minded person, in these cases the website might be unusable to someone with a different ability set than you. Accessibility enhances and eases the user experience and interface for everyone.

Accessibility compliance is more than just following a checklist. The spirit of accessibility is so that people of all ability types can access information. There are also judgement call situations, or situation where you could slack on an item because it is not an explicit WCAG guideline, but then you would put up a hurdle for users with disabilities. That being said. I will be offering you some measure of a checklist below on how to achieve WCAG certification for your website.

Why Get Certified?

There is no official governing body to certify WCAG compliance. The W3C is a collective group of people across the world that works on accessibility standards on a voluntary basis. There are some businesses that will audit and certify websites for commercial purposes, but this is not sponsored or certified by the W3C. There are various commercial companies that sell anywhere between a magic bullet solution/certification to in-depth solution overhauls. I couldn’t really endorse any without working with any. I am skeptical of the magic bullet solutions myself.

There are the official guidelines from WCAG, which it the source for what should be met: https://www.w3.org/TR/WCAG21/ . I reference this page often.

It would make things easier if there was a 508 government office to pro-active check and advise assets, but I think the only authoritative “checks” system is when someone is brought to court. (This is what it seems like to me, but maybe I am wrong?)

The WCAG does not officially require certification of a website. It is all on a voluntarily basis to show support for the cause. If every website was accessible, statements would not be needed. (How often do you see a restaurant advertising that is is ADA accessible? They just do it.)

To me, planning to self-certify the website (pending it passes) as it as authoritative as any other business and WCAG does allow for self-certification.

  • You need to know the guidelines:
  • You need to know programming, or know a programmer who can make the changes that you document. 
    • I highly recommend knowing some measure of HTML/CSS. Web-design level HTML/CSS is probably enough to get you by. Some errors are just easier to identify when one can inspect the browser code.
  • You need to be meticulous.
  • You need to have an empathetic heart.
  • If possible, it would be best to collaborate or contract with someone with disabilities for testing too.
  • You need to use screen readers on your computer/phone (more on that below).
  • You need time and patience. Documenting the bugs can take quiet a bit of time, and if there are time out issues, testing by a keyboard-only experience can take hours if the website is not optimized.

Start Here

Honestly, one of the simplest way to learn about accessibility is to go to the source: W3C. On their website, they offer a few different things:

  • An “easy checks” list. This is a quickie-list to get you started, but this should not be all of your testing. This is good for a sniff test on your site to see how much work it might need.
  • The full authoritative guidelines, itemized, detailed and exampled. I keep this open in a browser tab all the time. I often have to verify if an item is a Level A/AA/AAA requirement (basic- enhanced – stringent requirement). If you will be testing yourself (hey, it is cheaper, and maybe you trust your thoroughness more than some online vendor), read all the rules, understand them, and even look into the sample cases if it help with comprehension. Testing is a lot easier when you know these rules enough to look it up when you see something troublesome on your site, or have the rules memorized enough to quickly identify a fail.
  • A link to a free online class as sponsored by the W3C, with videos, text, and quizzes, that will get you going from, “What the heck is accessibility,” to specific developer tools to use. You can cover the initial chapters if you want to understand the legal and business needs, and if the final “dev” chapter is too confusing, you could conceivably skip it; I would recommend watching/reading it all, as the “dev” chapter is really conceptual, and will help you talk to developer, understand terminology, and not have the wool pulled over your eyes by “professionals” who will charge you a lot of money for your ignorance. 
    • I would recommend many of your team members taking this free class: the IT department, marketing, web designers, your coders, and the decision makers. One of the more frustrating things for me is when the production team knows why accessibility is important and worth doing, but the decision-makers who were too busy to do the online class, argue against the business value of all the man-hours because they are oblivious; if they took the class, they would at least know they are facing a potential ADA lawsuit, the same as not having a wheelchair ramp by having a non-accessible website.
    • I went ahead and paid for the certificate for my resume. If you only want the info, you can indeed learn it and run without paying a dime.
  • An accessibility statement generator. Once you have made the obvious choice to make your website accessible, this makes your first PR or internal landmark documentation a breeze.
  • A conformance report shell. This details the testing you did. I take it a step further and itemize the guidelines one-by-one as pass/fail.

Screen Readers

One you are familiar with the above, try using some screen readers for yourself! Test your site and test other random websites and see how it goes.

  1. Jaws for Windows,
  2. NVDA for Windows (free, but asks for donations)
  3. Narrator bundled with Windows (Free, it is already on your Windows Computer. Search your Windows computer for “Narrator Settings,” and do the start-up tutorial),
  4. VoiceOver bundled with MacOS and iOS (free)
  5. TalkBack bundled with Android (free)
  6. ChromeVox / Screenreader (extension to add on to Chrome; this is good for a quick “sniff test”)

Depending on your website, you might find that ChromeVox works best on Chrome, and Windows Narrator works best in Edge, although for example, Windows Narrator can work 99% of the time in Chrome. Every website is different and software updates often, so only you can pick-up on the quirks for your set-up.

Steps

  1. Get the whole team familiar with Accessibility. If you can’t afford everyone doing the online course, do a quick slide presentation with the basic concepts.
  2. QA Audit the Website.
    1. Do a gap analysis of where our product needs to be enhanced in order to comply. 
    2. Document issues  page by page, of what is not accessible and how it needs to be changes. I itemize issues on a 11×17 Word Document, inclusive of the page URL, the section of the page, specific steps needed to encounter the issue, the screen reader/tool used to find the issue, screenshots, and the propose fix/outcome.  Since I am a web designer, I write-in suggested HTML/CSS changes to the developer (if I am not the developer); I get very specific with my HTML/CSS edits so the programmers know exactly what I want. Other tips:
      1. You might split up features/sections to different team members.
      2. You might have different people with different focuses, before doing cross-checks. For instance, one person goes in an writes in all ALT attributes to images, while someone else is reviewing the tab order of objects.
      3. When I worked on a team to do testing/fixes, for me as the WCAG lead, it was easier for me to spilt the testing by WCAG rule. I ended up not doing that though. The developers felt better and had less issues with code mix-ups by splitting the fixes on a page-by-page basis; it certainly will make my certification process slow for me, but getting the developers to work on my code changes was difficult enough, so meeting them where they were made more sense. In the grand scheme of things, getting the developers to work on my fixes was more valuable then then chasing down code mix-ups.
  3. Develop and execute a plan for updating the website for WCAG 2.1
  4. User testing in-house and with real disabled users.
    1. I found a local non-profit that was for people with disabilities. They were happy to post the disability contracting job to their website. 
    2. I don’t think I am crazy, but I found some testers on my team weren’t getting it. They did not know HTML/CSS or they kept reporting reported issues or issues not in scope to the test plan. I found it easier to test thing myself. I spent time writing, verbalizing and showing in-person examples of what to look for. I then saw it was faster to do the testing myself, than to try to teach people HTML/CSS. The testing was too important to me to allow for such gaps. If I had continued, I’d have to re-test everything again because of my lack of confidence. Whatever was not found would not be fixed on it’s own. Every item has to be fixed for technical and spiritual compliance.
  5. Apply any needed fixes.
    1. Try to write down and track the issues, so you can cross off the issue as fixed. You’ll feel accomplished and your boss might like seeing the progress, as the change you make might not be visible to the naked eye.
    2. I think my boss at the time was getting concerned about the amount of time it was taking to fix everything. I decided to give him an end-of-month report to show what has been accomplished, or not. I was super worried when my report indicated 600 hours more of work, but he seemed okay knowing a number. I was also able to show the lack of tangible progress because one a handful of hours were used for the WCAG initiative, VS other project time. It kind of helped to show the project itself was not failing, it was that other project managers were sucking up the time.
    3. Keep on the developers to actually do the fixes. Having the fixes written down but not being worked on is useless; you have to go all the way. Other clients/ project managers may bark loud for developer time, so if you are managing the initiative, make sure you bark too. Don’t let this turn into a back-burner project. 
  6. Self-certify the website. Make a conformance claim:  https://www.w3.org/TR/WCAG20/#conformance
    1. I am attaching the sample conformance document here. This is one that made sense to me. Feel free to use it and copy and paste it into your own letterhead. It is basically a list of all the WCAG rules, plus some text as advised from WCAG/W3C. You might also want to convert this into HTML/CSS for placement on your website. Download Word Template
  7. Consider if you want to do a for-profit certification.
    1. If you are not confident that you found everything, this might be a route to go. There is also something to be said about having a third party test your website, as you could be metaphorically blind to something. That being said, vet the third-party company, as depending on how much programming you know, you might be better equipped to test the website yourself.  Proceed with any changes per the external certification requirements.
  8. Schedule an annual or bi annual accessibility evaluations of the website/s, to make sure new items are not meeting your standards. Make sure all new features are checked for accessibility before being released to LIVE.

References

 

About Ellice Sanchez

With her professional design experience starting in 2008, Ellice has done work for clients such as San Antonio Parks and Recreation, the City of San Antonio, Delicious Tamales, The US AirForce, Christus Santa Rosa, the University Health Systems, Sunset Station, Sushi Zushi Corporation of Texas, San Antonio Conservation Society, NIOSA, the San Antonio International Airport Concession, Representative Ivory Taylor, the Vidorra Condominiums, American GI Forums National Veterans Oureach Program, Republic National Distributing Company, Lifetime Fitness, Mr. W Fireworks, the RK Group, Pape-Dawson Engineers and other companies, working on projects ranging from signage, business cards, content management, design support, website design and coding, flyers, billboards and e-blasts.

View all posts by Ellice Sanchez →

Comments are closed.