During Codecademy's "Learn CSS: Variables and Functions" course, I was mildly disappointed to learn that CSS custom properties and fixed calculation functions were far less powerful than I had mistakenly thought from the course title. No matter, they are sufficient for their intended purpose, and they are valuable tools for building pages that are inclusive to all users. Which is why the next class in Codecademy's CSS curriculum is "Learn CSS: Accessibility."

First up is the size of text, the most significant factor in typographical design. This is a deep field with centuries of research from the print world, Codecademy can't cover them all and correctly doesn't try. We do get a bit of coverage on font-size, line-height, and letter-spacing. One oddity: a conversation on paragraph width introduces the CSS unit "ch" with 1ch being width of the zero character. ("0") This allows specifying lengths in a way that scales with the font, but that sounds like what "em" does as well. A quick search didn't find why we would use "ch" vs. "em".

Another topic was color and contrast. The expected color wheel discussion talks about selecting different colors with high contrast, but it didn't talk about color blindness. The course linked to a contrast checker tool by WebAIM, but it didn't mention color blindness, either. A quick search on WebAIM site found a page for color blindness, but it is incomplete. The page ends with an example: a train map where routes are represented by colors. The page tells us that the different routes would be difficult to tell apart for the color-blind, but it doesn't give us a solution to the problem! My guess? Maybe we can use different line styles?

This section also taught me there is a semantic HTML tag for denoting abbreviations.

<abbr title='Cascading Style Sheets'>CSS</abbr>

I don't think this should be classified as an accessibility measure because it would be helpful for all audiences. This information is certainly available to screen readers, but there is some visual indication on a normal rendering. My browser renders it as dotted underlined text by default. ("user agent stylesheet")

abbr[title] {
    text-decoration: underline dotted;
}

Another topic I didn't think should be classified as accessibility is a discussion on changing rendering for print media. This should have been part of the media queries course, but at least the concepts make sense. When the user is printing out a web page, we can do things like hiding a navigation bar that wouldn't have done anything on a sheet of paper. This course also talks about printing the URL of a link, because you can't click on a sheet of paper.

@media print {
  a[href^='http']:after {
    content:  ' (' attr(href) ')';
  }
}

However, this would only work for short URLS that can be reasonably typed in by hand. Many links of the modern web have long URLS that are impossible to accurately type in by hand. But on this vein, I think it would be worthwhile to print out the content of <abbr> tags as well.

Anyway, back to accessibility and screen readers. A section asserts that there are frequently items that are not useful for a screen reader and should be hidden. I think I understand the concept, but I thought the example was poor: In case of duplicate text, one of them could be hidden from screen readers with the aria-hidden='true' attribute. But it seems like the real fix is to remove duplicate text for all audiences! Another problem is this introduction of aria-hidden without saying anything more about it. A quick web search found this is just the tip of an iceberg called the Accessible Rich Internet Applications specification.

After the lecture, we are encouraged to read "Start Testing for Accessibility." A short overview of several accessibility testing tools: Lighthouse, WAVE, Axe, and Accessibility Insights.

I know I have a lot to learn about web accessibility, not the least of which is learning about other ARIA properties. But there's another side to the "not everyone sees the same web page as you do" problem: browser compatibility.