Very novice web-developer here designing a web-site for my new employer (US). I've been asked to ensure the website is accessible to avoid any potential legal issues. I went looking for specs and saw WCAG 2.0 which, to me, was absurd. For videos there is supposed to be captions, a transcript, and a sign language interpretation of the video - which were all rated the highest priority in the specs (AAA)...

From my understanding, the ADA and DOJ never named any specific requirements to make a commercial site accessible. I'm using a CMS (Drupal 8) which claims to be accessible out of the box, but I'm very curious now, what standards do we go by to ensure a good experience for disabled users? Aside from proper HTML for screen-readers and alt-text for media I'm clueless.

  • 4
    As I understand it, AAA is their most strict level of compliance, not highest priority. The project I'm working on now is being designed to AA level. May 2, 2016 at 21:22
  • In Australia there are federal legislations in place to ensure government websites meet the AA level (and AAA where appropriate), but I am not aware of any requirements for commercial websites.
    – Michael Lai
    May 3, 2016 at 1:23
  • @MichaelLai Australian federal goverment websites require Level A (being upgraded to Level AA over time, meaning it is too hard for most of them), they say that in some cases it will be Level AAA. Government apps are all Level A at best (find me an app that works in landscape!). Australia isn't a good example for Accessibility implementations.
    – straya
    Feb 10, 2020 at 6:00
  • @straya I agree but it seems like not many governments around the world is setting a shiny example. Which country do you think is the gold standard for accessibility? I do think that the US Government Design System is better than the GOV UK and Australian Government Design Systems, but it is not an exact science when it comes to comparing these things.
    – Michael Lai
    Feb 10, 2020 at 23:04
  • American airline ticketing systems are under the most scrutiny w.r.t. Accessibility worldwide, that is where the first legal cases arose and the industry that got the most attention from ADAAG plus the Air Carrier Access Act: WCAG Level AA was first mandated for that industry, many other industries use that as the minimum bar so as to mitigate the risk of being sued.
    – straya
    Feb 11, 2020 at 1:35

8 Answers 8


WCAG2.0 is the currently generally-accepted standard for accessibility. Section 508 compliance checklists also exist (http://www.section508.gov/summary-section508-standards) but may be outdated: the original 508 guidelines are comparatively vague, and were written before e.g. screenreaders could interpret javascript so are more restrictive than necessary.

You've misinterpreted the level ratings in WCAG: they're not "priorities", they're different levels of conformance. Most organizations aim for at least A-level conformance; few go all the way to AAA-level conformance because, as you point out, that level of accessibility is challenging to meet. In fact:

"It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.") http://w3.org/TR/UNDERSTANDING-WCAG20/conformance.html

To consider your product accessible, it must meet level A, it should meet level AA, and it may meet level AAA.

You may also wish to review the VPAT template at https://accessibility.oit.ncsu.edu/training/accessibility-handbook/vpat.html, which is essentially a self-assessment checklist of "does this product meet WCAG?" in standardized form.

(I'm coming back late to edit this answer to echo an important point made in other answers: the checklist is only the first step; it's important to actually test the design for accessibility and make sure it's truly usable by all. It's quite possible to build a product which technically meets all the guidelines, but is still unnecessarily difficult or annoying to use.)


The most common level of WCAG adherance is AA, which does not require some of the things you were likely initially turned off by. Using your example, WCAG 2.0 AA does require closed captioning on videos, but does not require a sign language interpretation. To learn more on your own, consider an online course. I can personally recommend the courses from Deque University: https://dequeuniversity.com/curriculum/online-classes (this one does cost money - maybe your manager could spring for it?). But I'm sure there are others out there for accessibility beginners.

This concerns me:

I've been asked to ensure the website is accessible...

The responsibility should never fall solely on the developer. UX, QA, and others need to design and test for accessibility as well.

Some examples of things designers and content folks (UX or otherwise) need to take into consideration when designing:

  • users of zoom software will not see the entire screen, so messages that dynamically appear on screen won't display to them unless they move around to view it
  • screen reader users often listen to a list of links or headings on the page as a way of scanning the page's content. If the heading structure is used for aesthetics rather than proper markup, those users will suffer. If a page is full of a bunch of "read more" links, the user won't understand what the link is.
  • if a video with lots of speech or other audio doesn't contain the option for closed captioning, a person who is deaf or hearing impaired cannot get your message.

And without some level of QA, you'll never know if your efforts are successful or not.

So make sure to get the entire team on board!


Keep in mind that the best way to ensure that you meet accessibility requirements is not to simply run through a checklist of criteria that are mostly based on technical implementation details. WCAG 2.0 guidelines were very specific about doing 'human' testing to ensure that the site does more than just meeting technical specifications because it is only half of the story (in terms of making it visible to assistive technology).

The best test is to actually try using the website as someone requiring accessible features would use it, so for example using the website without a mouse, running a screen reader application, running a colour blindness simulation application, etc. Some people have even suggested blindfolding a normal user and getting them to access various part of the website so that one understands that purpose for placing accessibility as a requirement for websites.

More importantly, don't think of accessibility as a requirement but as an approach to design and implementation as part of the bigger picture under inclusive design - after all, the web should be available for everyone regardless of what their specific requirements are (in theory anyway).

  • 1
    +1 for "More importantly, don't think of accessibility as a requirement but as an approach to design..."
    – jazZRo
    May 3, 2016 at 9:47
  • @jazZRo wish I could get a +$1 every time I have to tell people this when they are doing design and testing for accessibility :D
    – Michael Lai
    May 3, 2016 at 21:55

You mentioned you are a novice developer. In addition to the other great answers I want to answer on that perspective.

HTML and CSS are designed with accessibility in mind. Making good use of them is the first step. It's not just about following W3C guidelines but also understanding them. Understand the semantics of HTML elements, learn about aria attributes and use CSS properties as supposed to. A clean design can help making the implementation easier.

Also evaluate accessibility early and often: These pages from w3.org can guide you through this evaluation.

  • 2
    +1 for "HTML and CSS are designed with accessibility in mind." It seems to me that lots of accessibility problems are caused by adding (unnecessary?) bells and whistles to good clean html/css. May 3, 2016 at 13:17
  • +1 also for evaluate accessibility early and often!
    – Michael Lai
    May 3, 2016 at 21:56

As some have already mentioned, WCAG is the one to look at. I've found this visual tool extremely helpful - keeps in focus some of the tasks you need to achieve depending on which level of WCAG you want to meet and breaks them on into the different disciplines responsible for actioning them (Dev, UX, etc)

Also keep in mind WCAGs overall objectives - but don't forget to look at accessibility from a UX perspective, these you want what you to create to be usable for people with accessibility requirements as well.

  • Perceivable
  • Operable
  • Understandable
  • Robust

Section 508 VPAT checklists are due for a refresh, because they are now very old, and will soon be adopting WCAG 2.0 to bring the USA in-line with the standards used by the rest of the world https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/proposed-rule/ii-executive-summary


It's time to think around WCAG 2.1 guidelines as they will be legally applied by mid 2020.

WCAG 2.1 provides 17 additional success criteria to address:

  • mobile accessibility
  • people with low vision
  • people with cognitive and learning disabilities

Official details at what's new in WCAG 2.1


Since there is no accepted answer to this maybe you need to look from in a different direction. Do you want to make your website/application ADA complaint yourself? Or you are looking for a library/third party which will do the job for you? For 2nd part of your question if you use a third party to ensure that your company doesn't run into an ADA compliance lawsuit then you don't need to worry about any standards, they will take care of it for you and your company. My company ran into a similar issue last year and after a number of board meetings, our directors decided to use a third party rather than spending time adhering to the standards that change every now and then.

See accessibility is not basically a requirement its an approach to how you design your application. Have a look at this article which actually explains your problem exactly and there are some recommendations too. For the record, we decided to go with accessiBe for our product, and its been quite good so far.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.