The WCAG guidelines are a good starting point, but they're starting to age poorly. The number one source I suggest supplementing them with is the Nielsen Norman Group. Their articles are based on actual UX studies with actual people, instead of the wild guesswork and card-stacked lies so common elsewhere.
nnGroup is also utterly reviled by the fools calling themselves "web designers" whilst only knowing how to shove pixels around in Photoshop. Makes it a hundred times more credible in my book if they're pissing off those ignorant clowns who's lack of understanding HTML, CSS, JS, limitations of the medium, emissive colourspace, or accessibility norms leaves them qualified to "design" but two things -- and Jack left town.
They have articles and research dating back nearly two decades, actual scientific papers with double-blind studies, and are one of the few places offering coursework that I would actually recommend.
Interpreting the language of the WCAG is also tricky as the language barriers common to all W3C creations gives it the feeling of having been written in swedish, translated to Japanese by a Russian, then google translated to what can only be described as "Engrish moist goodry, me love you long time."
The math of things like the legibility rules is also a bit off/akilter as normal people often don't grasp it, and things like font-smoothing (a technology that wasn't even in OS when the WCAG was created) mean to truly meet it you have to go by a screencap zoomed in of a rendered page and NOT the colours you declare in your CSS.
The math for me seems simple, but that's because I've worked directly with YCbCr implementations, and the luma for the WCAG rules is just Y.
Thankfully WebAim -- itself a fairly reliable source of advice:
Has a tool to help with knowing what levels of WCAG standard your fonts meet:
webaim.org/resources/contrastchecker
A quick rule of thumb is that with thin-glyph fonts -- like Google's DREADFUL "raleway" you should treat a larger size as "normal AAA" and avoid using it at "normal" sizes (16px / 1REM) or smaller altogether. Thanks to font-smoothing which blurs the bars and slabs on glyphs, you will end up more often than not having to treat normal text as needing to meet AAA at all times. It sucks but these technologies that improve the shape and form of the glyphs actually compromises legibility. Microsoft tries to address this with core fonts by hammering them into pixel boundaries, whilst Apple's answer is to make everything feel bold/blurry. Neither is actually a great answer on the majority of normal displays.
Though retina / hdx / high pixel density displays are slowly changing that, not everyone can afford that or is likely to want/need it any time soon. Particularly since even Joe Sixpack and Susie Sunshine continue to scoff at 4k as placebo instead of fact, waiting until they NEED a new display to take the plunge.
... and there will always be a place and platform for cheaper displays.
Likewise be warned that due to its age, it's easy to take parts of the WCAG out of context, like the part saying that pixels can be acceptable when user agent support for scaling override is present. What they are referring to is how Firefox USED to handle them Netscape 4 style, the IE7/earlier behavior, and how "classic" Opera's zoom/scaling worked which would actually override your layout styles if possible to maintain a working layout. As such that part can no longer be used as justification for declaring font sizes in pixels since neither UA behavior is still in common circulation. Not that it was ever justifiable given how IE dropped the ball when they moved to 8, firefox ditched it some time around 2003, and blink/webkit/khtml never supported it. -- That's why of all the sizes the WCAG says are usable for font-size, %/em is for screen, pt is for print.
BUT there are those who will read that same section and interpret it differently. They're quite shocked when prosecutors, civil litigators, and judges disagree.
Hence why I often joke "The WCAG says to use EM, so use 'em!"
But really, for ALL the things the WCAG says, 99% of staying out of trouble and being properly compliant can be achieved by:
1) Having proper semantics. Say what things ARE, NOT what you want them to look like.
2) Establish a logical document order where your H1 (singular) is THE heading that EVERYTHING on every page of your site is a subsection. H2 indicating the star of a major subsection of the page with the first H2 being the start of your primary content. (what HTML 5 added their pointless MAIN tag for). H3 being the start of a subsection of the H2 before it. H4 being the start of a subsection of the H3 before it... all the way down to H6. HR -- horizontal rule --even means "a change in subject or topic where heading text is unwanted/unwarranted" and NOT "draw a line across the screen"
All stemming from the fact that HTML tags are not for presentation, and if they seem to have presentational meaning that's because they represent what things WOULD BE for grammatical reasons in a professionally written document, and NOT "it must be shown this way". Particularly when many HTML compatible UA's are incapable of showing bold, italic, font-sizes, drawing lines, etc. A detail many people miss completely!
To that end I also suggest skipping past all the new HTML 5 tags that are SUPPOSED to provide that same functionality (pointless redundancy) that not one legitimate accessibility UA actually obeys. (making it toothless). That means do not waste your time on, or do not rely upon ARTICLE, ASIDE, NAV, MAIN, HEADER,FOOTER, or SECTION.
...and if you do use SECTION beware that it utterly screws up legacy support as the rules for using it 'modern' style means if you open SECTION you're now back to H1 depth. Basically under HTML 5 rules it's "start with H1 as your heading depth for each BODY or SECTION". End result being that headings other than H1 being correct/appropriate reaches near to zero. There's a reason a lot of HTML 5's die hard fanboys even suggest that SECTION should be axed.
In general those tags speak to having been made by folks at the WhatWG who never embraced HTML 4 Strict, read the WCAG, or grasped any of the core concepts of semantic markup. For all it's improvements, those tags I just outlined are if anything a step backwards to mid '90's methodologies undoing twenty odd years of progress. It's why some people will tell you "Code for 4 Strict, but deploy as 5 for the handful of advantages".
The same goes for that Aria role nonsense -- mostly redundant to semantics, mostly nothing more than code bloat, and few if any legitimate UA's do a blasted thing with them. That entire specification seems to have been created for the microformat junkies to have their own little corner to spank it in, and to satiate the wants and desires of "data scrapers"... or if we were to refer to them by their proper name, CONTENT THIEVES!
... and of course neither are listed in the WCAG as they're too new, and it's so old. Also I wouldn't plan on seeing the WCAG updated in our lifetimes given many top names at the W3C hate it because it has hard strict rules that clashes with their
Aka the type of people you might actually want to keep OUT of your website. You want that type of data passing, set up a REST service and stop trying to use HTML to do things it's not designed for.
Moving on.
3) Elastic layout. Declare EVERYTHING possible in EM's. That means margins, padding, font-size, line-height, and your media query breakpoints for responsive design!
4) Semi-fluid layout. Aka having a max-width so long lines aren't hard to follow.
5) Responsive layout -- whilst so new the WCAG doesn't even mention it, maintaining a useful layout prevents OTHER parts of the design from creating new violations.
6) Scripting off/blocked functionality -- I'm not saying don't use JavaScript, JS can be applied in a compliant manner. But if your page's base functionality and usability goes bits-up face-down when JS is blocked/unavailable, you ARE in violation under most LEGAL interpretations.
7) Graceful degradation -- every care should be taken so that if newer bits of the specifications (like JS, CSS, or HTML) are missing, or if specifications like images, media, CSS and JS are blocked / unavailable / inapplicable, you are still delivering a useful and useable website.
Which is why I'm endlessly advocating the progressive enhancement development approach.
You do those seven things, and you are close enough to compliant that NOBODY will nitpick any of the other details. In most jurisdictions if you have those simple things, it's your get out of jail free card.
Now think about how many of those things the majority of off the shelf templates and HTML/CSS/JS frameworks fail to deliver on, or worse outright INTENTIONALLY seem to want to piss all over.
You may enjoy a few of my own articles on the topic of progressive enhancement since it relates to meeting these norms.
cutcodedown.com/article/progressive_enhancement
My article on "what's wrong with YOUR website" is starting to age like milk, but still has some key insights that go above and beyond what the W3C offers.
cutcodedown.com/article/whats_wrong_with_YOUR_web…
That help any?
Kevin C.
Re-learning after an 8-year hiatus