Stay up to date with weekly industry insights

the latest trends in web design, inbound marketing, mobile strategy and more...

Web Accessibility, Section 508, and Your Web Project

Web Accessibility, Section 508, and your web project

Theres a lot of misinformation out there when it comes to Web Accessibility, so understanding what your obligations are as a designer, developer, or website manager can be challenging. Everyone involved in planning, building, and maintaining websites has accessibility concerns to be aware of. It's time to clear up some of the ambiguity surrounding the need-to-knows of Web Accessibility.

WCAG vs. Section 508

If you’ve done any of your own research into accessibility requirements, you may have come across reference to WCAG and Section 508. "Section 508 Compliance" is sometimes listed as project requirement, and I often hear it being used interchangeably with web accessibility—as though they are one in the same. Each time this happens I cringe a bit, and picture that scene in the Princess Bride when Inigo Montoya observes, "You keep using that word. I do not think it means what you think it means."

Animated Image from the Princess Bride: You keep using that word. I do not think it means what you think it means.
How well do you understand web accessibility? Section 508 may not mean what you think it means.

WCAG 2.0

Let’s begin by establishing what’s what. WCAG stands for Web Content Accessibility Guidelines. It’s not law, but rather the go-to body of accessibility guidelines, developed to ensure that information delivered on the Web can be accessed by people with visual, auditory, learning and physical disabilities. WCAG 2.0 is the current standard, recognized internationally, and is applicable to all websites, including yours!

Its the ethical responsibility of designers (and this includes everyone who contributes to the sites we build), to do their best to make sure that the sites and applications put out into the world are fit to be consumed for all users, including those with impairment. Although in our case we deal with Web Accessibility, the principles outlined are the same as those described when people talk about Inclusive Design or Universal Design. WCAG 2.0 guidelines include conformance ratings of A, AA, or AAA, corresponding to level of impact toward accessibility2.

  • Level A (minimum) – the lowest bar web accessibility features
  • Level AA (mid-range) – the typically targeted range, which deals with the biggest and most common barriers for disabled users
  • Level AAA (highest) – the highest, sometimes unobtainable, level of web accessibility

Section 508

Section 508, is a law introduced in 1998 as an amendment to the Rehabilitation Act of 19733. It establishes the accessibility rules that federal agencies must comply with when procuring, using and maintaining all forms of information and communication technology.This includes: websites, apps, software, multimedia, electronic documents, and more. As it applies to the Web, what you need to know is that the Section 508 law specifies which WCAG guidelines you are required to conform to, and at which level. Spoiler alert: you’ll basically need to follow all of them, and at Level AA. Here’s the quick reference guide.

Who does Section 508 apply to?

While WCAG 2.0 are guidelines that apply to everyone, section 508 is a law that applies only to government agencies and initiatives. It does not apply to the private sector, and contrary to popular belief, it does not apply to recipients of government funds4. If you aren’t a federal agency, you most likely are not bound by it. Some organizations may have instituted their own policy that requires their site be Section 508 Compliant. In those particular cases it would be a matter of scope and not legality. If you are unclear about whether or not you ’re legally required to comply with Section 508, you can use this tool or contact an accessibility consultant.

Project Tips for WCAG and 508 Compliance

  1. Establish requirements first. If Section 508 compliance is a project requirement, make sure to establish it and discuss before contracts are signed, and again at the onset of the project. Design, development, testing, and content creation will all impacted. It’s much better to create and follow checklists early on than to go back, cross your fingers and test accessibility after the work is done. For example, many colors combinations do not meet the minimal level of contrast to ensure visibility, so it may affect how your brand colors need to adapt for the Web.
  2. Identify technology constraints before signing contracts. In certain cases, for example, when implementing theme packs, adopting certain platforms, or relying on 3rd party code, it may not be possible to meet all AA WCAG 2.0 guidelines. If you are legally committed to Section 508 compliance, you should be evaluating this early on during the project planning procurement phase, before purchases are made.
  3. Plan extra time for testing. Testing to ensure that your web pages work with assistive technology (like screen-readers) is important but takes time. Dust off those screen-readers!
  4. Plan training sessions. Train content teams to understand their role as it applies to producing and maintaining accessible content.
  5. Set expectations. Even if Section 508 compliance is not required, discuss expectations with everyone involved in the project. For example, required or not, it is our internal practice to meet WCAG 2.0 level 2 (AA) guidelines. This is a reflection of our ethics and commitment to designing for everyone.

How to handle inaccessible design requests:

Whether you are a project decision-maker, creator, or co-creator there is no relinquishing accountability for what you have built and introduced to the Web. Inevitably, you will face a client or an important internal stakeholder that will ask (or insist) you to do something that violates an established accessibility guideline. Here are some of the arguments you might hear:

  • "What do our analytics show? We arent seeing any evidence of traffic from screen-readers. Disabled users make up less then .01% of traffic!"
  • "Those rules don’t apply to us, because [excuse]."
  • "We’ve gone this long without any problems, I’m confident it won ’t be a problem. If it becomes one, we can address it then."
  • "We understand your concern, but grant you permission to do what we told you to do."

When you encounter those types of objections, here are some ways you justify your position:

  1. Use your judgment. WCAG guidelines are just that: guidelines. Would you feel irresponsible for accommodating the particular request?
  2. Describe the UX value. Explain that the guidelines aren’t just there to accommodate people with disabilities. Adhering to them improves usability and experience for all site users.
  3. Talk about future-proofing. Accessible content and design tend to be more future friendly, making it more "future-ready" to be consumed by emerging technology.
  4. Take an ethical stance. Designing accessibly is the right thing to do as people who make websites. Designing accessibly is the responsible thing to do as organizations publishing their content online.
  5. Talk in terms of people. Explain what the aforementioned types of disability actually entail and how it applies to the site design. For example:
    • High contrast, larger text, and easily identifiable links are improve usability for older users, people with low vision or different types of color blindness.
    • Large buttons, easy-to-use navigation, and enabled keyboard control helps people with poor manual dexterity. This might apply to people who have tremors as the result of chronic illness or medication, and people with rheumatoid arthritis among others.
    • Alt text, video transcripts, and keyboard access, can be set up to help users who rely on assistive technology to consume web content.
  6. Explain how lawsuits work. While you won’t be busted by the internet-police for not adhering to WCAG guidelines, following them WILL help mitigate risk of being sued by individuals or third parties claiming that your site discriminates against users with disability and is in violation of the Americans with Disability Act. These are the types of lawsuits you hear about in the news, and that can result in mediation or court decision to determine negligence and damages.

Be Awesome.

Web Accessibility is not about ticking off a box in a requirements document, or abiding by legal constraints. It’s about making things that are useful and usable for everyone.

Don’t get bullied into decisions that will knowingly make your site harder to use for disabled users.

That’s called lousy design. Period. You aren’t a lousy designer or product manager, right? Accessibility is about caring enough about your work to take the time to consider the needs of the real people who have to use the stuff we make. Designing accessibly is awesome. Go be awesome!


Resources:

  1. If you have the time, check out these stories to better understand some of the barriers that people with different disabilities face while trying to use the Web: https://www.w3.org/WAI/intro/people-use-web/stories
  2. WCAG overview: https://www.w3.org/WAI/intro/wcag.php
  3. Everything you need to know about Section 508: https://section508.gov/
  4. Accessibility checkers and browser plugins: https://www.w3.org/WAI/ER/tools/
  5. Intro to Accessible Design: http://webaim.org/intro/

References:

  1. https://en.wikipedia.org/wiki/Web_accessibility
  2. https://www.section508.gov/content/build/website-accessibility-improvement/WCAG-conformance
  3. https://www.section508.gov/content/learn/laws-and-policies
  4. https://www.access-board.gov/guidelines-and-standards/communications-and-it/25-508-standards/720-questions-answers-about-section-508-of-the-rehabilitation-act-amendments-of-1998#3)

 

About the Author

Dennis Kardys
Dennis Kardys
As WSOL’s Design Director, Dennis focuses on helping clients realize the importance of user-centered design and developing elegant and intuitive websites. He is responsible for collaborating with clients to flesh out the vision for their project, running UX and discovery workshops, and working between teams to ensure that visually, conceptually, and functionally, each project lives up to its potential. Dennis has over 12 years of combined experience in visual design, user experience, and web development. He is a recognized speaker, writer, and contributor within the UX and web design communities, and is obsessed with topics like responsive design, the mobile web, and design ethics.