WCAG Compliance: Accessibility as a Real Constraint

· How I've made this site compliant with WCAG 2.

#audit #web

1. WCAG 2

What are the Web Content Accessibility Guidelines (WCAG) 2 requirements?

While the full list of WCAG requirements may seem intimidating, it's actually straightforward for a static site like cleberg.net if you are intentional about design. Luckily, they offer a Quick Reference guide that is much easier to parse than the full specification.

So, while it wasn't onerous to push myself over the 100% threshold, I wanted to write about how my current website design contributed to my compliance rate and why WCAG is important.

2. Why WCAG?

Before I dive into the specifics of how my website complies with these requirements, I wanted to touch on the importance of WCAG itself.

There are three major reasons I wanted to implement the WCAG requirements on my website:

  1. Usability: The main reason, which I've covered in numerous other blog posts about minimalism and design, is usability. I believe that our tech should always serve a purpose and I believe that the design of a tool should encapsulate that idea. Therefore, designing a website with intent leads to better usability, both by those with and without disabilities.
  2. Kindness: What's better than designing a tool accessible by everyone? Personally, I love the idea that no matter who visits my website, they should experience the same content and same utility intended by the website.
  3. Future-Proofing: Technology, include internet tools, are changing constantly. When a website is well-designed, reachable by all audiences, and utilitarian, it will be able to last longer or even "decay gracefully".

3. Implementing WCAG On My Website

Since I do not implement JavaScript, forms, or multimedia content on my website, the list of items to implement was short.

I'll go through some of the items that I considered during my manual verification of the site. If an item is not on this list, it is either not applicable or the native browser functionality covers the requirement and I do not implement any custom element that would require verification.

  • [1.1]: Text alternatives for non-text content (i.e., images)
    • For each image within my website, I made sure that alt-text was available.
  • [1.3.1]: Use Accessible Rich Internet Applications (ARIA) landmarks to identify regions of a page
    • ARIA landmarks are available for the navigation menu on my website, which is the only element I use which is recommended by WCAG to have an ARIA role.
  • [1.3.1]: Use semantic HTML elements to identify regions of a page
    • I have always used semantic HTML, but I reviewed my HTML templates to ensure I had coverage. In short, I use elements like <nav>, <main>, <article>, and <footer> instead of <div> elements.
  • [1.4.1]: Use a color with a relative luminance difference of 3:1 or greater
    • When choosing the color palettes for this site, I ensured that all were at least AA compliant and in most cases, AAA compliant.
  • [1.4.4]: Use em (or rem) units for font sizes
    • All sizing on this site uses rem sizing.
  • [2.4.1]: Create links to skip blocks of repeated material
    • I created a skip-to-content link hidden at the top each web page that allows keyboard or screen reader users to skip the navigation block.
  • [2.4.6]: Provide descriptive headings
    • Each page contains hierarchical headers starting at <h1>.
  • [3.1.1]: Use the language attribute on the HTML element
    • Each pages is defined with <html lang=en-us>.
  • [3.1.4]: Provide an expansion of an abbreviation on the first occurrence
    • To the best of my ability, I have been reviewing all historical posts on this site and expanding abbreviations upon first use.
  • [3.2]: Make web pages appear and operate in predictable ways
    • This, and many other requirements, are resolved by a combination of (1) native browser functionality which works as expected since I am using semantic HTML, and (2) my use of a structure outline and logical content flow on each page of the site.

4. Results

Results from the IBM Equal Access Accessibility Checker, showing 94% confirmed compliance, with the remaining manually confirmed.
Figure 1: IBM Equal Access Accessibility Checker

To confirm compliance, I chose not to use one of the "free" accessibility checker websites, since they often only test one page at a time, take a while to run, and I just generally don't enjoy scanning my website with random services.

Instead, I used the IBM Equal Access Accessibility Checker extension on Firefox. This allowed me to scan each page I wanted, stored my scans, and provided in-depth results with links to guidance and suggestions for fixing each issue.

This was great as it showed me a handful of issues I hadn't caught previously. However, the image above shows that my site is 94% compliant through automated checks and I manually verified the remaining 6% of checks.

I performed these scans for all top-level pages on my website (home, about, blog, services, about, salary, and now), as well as the three latest blog posts to confirm compliance.

I'd love to test 100% of every page of my website one day and will continue to strive to enhance my compliance with ARIA and WCAG.

Reply via email →
...or, comment on this post on Bubbles!