A few years ago I didn’t know what the term “accessibility” meant. I built Web sites that were partially inaccessible because I didn’t know better. Fast forward to today, I know enough to be able to write, speak and run workshops on accessibility, helping others build more a accessible and inclusive Web. Much like everyone else in our field, I am still learning. But since I started, I learned a lot of valuable lessons and core values that drive my work today. Here are a few of them.
Semantic HTML is the foundation of a truly accessible Web.
Semantic HTML is the universal language that all devices accessing the internet understand. It is the language you use to communicate your content to these various devices, including but not limited to browsers, reading apps, screen readers, smart watches, and more.
HTML is semantic, or in other words, it is descriptive and provides meaning — each HTML element describes the type of content it presents. So if you have a heading, you use a heading element. If you have a paragraph, you use a
tag. In other words, it means using the correct HTML elements for their correct purpose.
By using correct elements, your document content will have conveyable structure and meaning.
Structure is important because it helps interoperability. Interoperability is the ability of different systems, devices, applications or products to connect and communicate in a coordinated way, without effort from the end user. In other words, it allows more devices to interpret and access your content, including devices that will show up in the future.
Structure helps applications like reading apps and reader modes (such as Safari’s reader mode) as well as environments like Windows High Contrast Mode understand your content and style it in ways that improve the user experience. This is only possible when the proper HTML semantic elements are used, such as
, , , among many others available in HTML. These elements describe the type of content they contain. Without them, these applications wouldn’t be able to tell what that content is, and therefore won’t be able to style it properly. This increases the risk of making the content less accessible, if not completely inaccessible.
Structure is also important because it allows your users to navigate your content more efficiently. Screen reader users rely on proper document structure to jump to areas of the page they need more quickly. They do that using various quick/hot keys — power commands but for screen reader users. If you don’t use proper landmarks (exposed to screen readers via semantic HTML elements like
I’ve been using CSS as a web developer since CSS became something we could actually use. My first websites were built using tags and
s for layout. I remember arguments about whether this whole CSS thing was a good idea at all. I was quickly convinced, mostly due to the ability to easily change the font on an entire site in one place. Managing common styles was so useful at a time when most websites were just a stack of HTML pages with no management of content or any form of templating. I was an early adopter of using CSS rather than tables for layout, despite the backdrop of people asking, “but what about Netscape 4?”
CSS is a remarkable language. Those early sites were developed in a time where the best we standards advocates hoped for was that browsers would support the CSS that existed; that developers would validate their HTML and CSS and use the CSS that existed. Yet, a website built back then that is still online, or one accessed via the Wayback Machine will still work in a modern browser. Such is the care that has been taken to not break the web by the CSS Working Group, and the other groups working to add features to the web platform.
I’ve been teaching CSS for almost as long as I’ve been using CSS. I’m incapable of having a thought without turning it into words. I write things down to remember them, I write things down to help them make sense to me. This leaves me with a lot of words, and from the earliest days of my career I had an idea that they might be useful to other people and so I started to publish them. Over the years I’ve learned how to teach people, discovered the things which seem to help the various concepts click for folk with different ways of learning and processing information. Since the early days of CSS layout, we’ve been teaching it along the following lines.
this is a block thing
this is an inline thing
you can turn the block things into inline things and vice versa using the display property
this is the Box Model, it is very important and also kind of weird.
Typically we would teach CSS by jumping right in, styling up a layout and explaining the strange collection of hacks that allowed for a layout as we went along. Unlike other languages, where we might start with the core fundamentals of programming, in CSS we had very few concepts to teach outside of building things and explaining the weirdness in the context of actual layouts. The Box Model was important because it was all we really had in terms of layout. It was core to our method of giving things a size and pushing them around in a way that would allow them to line up with other carefully sized things to make something that looked like a grid. If you didn’t understand the standard Box Model, and that the width you set wasn’t actually the width the thing took up, your carefully calculated percentages would add up to more than 100%, and bad things would happen.
Over the last few years, we’ve been handed all of these new tools, Flexbox and Grid give us a layout system designed for CSS. Perhaps less obviously, however, a set of concepts are emerging that give us a real way to explain CSS layout for the first time. There has been something of a refactoring of the language, turning it from a collection of hacks into something that can be taught as a cohesive system. We can start with normal flow and move onto what it is to change the value of display because it is here that all of our new layout capabilities live. We can share how display controls two things – the outer value of block and inline and the inner formatting context – which might be grid, or flex, or normal flow.
Explaining Writing Modes early on is vital. Not because our beginner is going to need to format a vertical script, or even use vertical writing creatively immediately. It matters because writing modes explain why we talk about start and end, and the block and inline dimensions rather than the physical top, right, bottom and left corners of their screen. Understanding these things makes alignment in grid and flexbox and the line-based positioning in grid much easier to understand. The Box Model can then drop back to a brief explanation of the fact that width and height (or inline-size and block-size) relate to the content-box and we can change it to relate to the border-box with the box-sizing property. In a world where we aren’t giving things a size and pushing them around, the Box Model becomes just part of our discussion on Box Sizing, which includes the intrinsic sizing far more useful when working with flexbox and grid.
Finally we need to focus on the idea of Conditional CSS. Media Queries and Feature Queries mean we can test the environment of our user using metrics such as their viewport size, whether they are using a pointing device or a touchscreen, and the capabilities of their browser. We can never be sure how our websites are going to be encountered, but we increasingly have the ability in CSS to optimize for the environment once we are there. One of the greatest skills we can give to the person beginning their journey as a web developer is an understanding of this truth. The person visiting your site might have a touchscreen, they might be using a screen reader, they may be on a small-screen device, and they might be on IE11. In all of these cases, there are things you want to do that will not work in their situation, your job is to deal with it and CSS has given you the tools to do so.
As I started my CSS layout journey with a backdrop of people complaining about Netscape 4, I now continue against a backdrop of people whining about IE11. As our industry grows up, I would love to see us leaving these complaints behind. I think that this starts with us teaching CSS as a robust language, one which has been designed to allow us to present information to multiple environments, to many different people, via a sea of ever-changing devices.