1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
#+date: [2025-11-14 Fri 19:46:30]
#+title: WCAG Compliance: Accessibility as a Real Constraint
#+description: How I've made this site compliant with WCAG 2.
#+slug: wcag
#+filetags: :audit:web:
* 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 [[https://www.w3.org/WAI/WCAG22/quickref/][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.
* 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".
* 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.
* Results
#+caption: IBM Equal Access Accessibility Checker
#+attr_html: :alt Results from the IBM Equal Access Accessibility Checker, showing 94% confirmed compliance, with the remaining manually confirmed.
[[https://img.cleberg.net/blog/20251113-wcag/accessibility_assessment.webp]]
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 [[https://www.ibm.com/able/toolkit/tools/#develop][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.
|
