Accessibility has been a big part of my development process for more than 16 years. In that time, I have learned a lot of things. The biggest thing I have learned is that you can never stop learning about accessibility because, as technology changes, the tooling and implementations change slightly. More importantly, as Siteimp, Formimp and my consulting company start moving towards Canadian Federal Government accessibility requirements , we move towards requirements that focus on accessibility for all, regardless of sensory or cognitive abilities. It will require some work on all our properties but it's worth it because CAN/ASC - EN 301 549:2024 is an excellent document.
Even though building accessible websites and applications is a lifelong learning process, I have come up with ten things anyone can start doing right now. Following these tips will not guarantee a perfectly accessible product, and this sure as heck is not a compliance document. But if you practise these tips, you will move the needle in a positive direction.
Ten tips to build more accessible websites and applications
- Learn to use one screen reader well enough to get through your day-to-day work with it.
- Colour matters a lot, so pay attention to contrast ratios. But do not rely only on colour to convey meaning.
- Write semantic HTML.
- Add alt text for images.
- Provide captions and transcripts for media.
- Support full keyboard navigation.
- Pay careful attention to your headings. Make sure they are clear and hierarchical.
- Make sure all your links are clear and descriptive.
- Make sure your forms are accessible and well labelled.
- Most drop-in accessibility overlays are complete garbage. See 1.
I'll take some time to go over each of these now and go deeper into why these ten things will move the needle. However, any accessibility advocates are likely wondering why I don't have ARIA roles and attributes anywhere in there. ARIA, or Accessible Rich Internet Applications, is a fundamental tool in accessibility, but it's easy to get custom controls wrong. So easy that I think you could break up all custom controls into helpful and harmful buckets. Even if properly implemented, ARIA is not a shortcut, and so, while it is very important, if I wrote 12 tips here, ARIA would make the cut. It won't move the needle until the person implementing the custom controls is good with a screen reader, understands semantic HTML, and has likely integrated all ten of these practices into their normal development flow.
Learn to use one screen reader well enough to use it as your daily driver
When I was writing the list, I wanted to say "in no particular order," but that's not true. This is by far the most important investment that anyone reading this can make right now. If you don't know which one to start with, NVDA is an excellent choice .
Why is this number one? It's simple. Every other tip here will just fall into place when you have used a screen reader to do all the things you normally do. You'll discover that a whole lot of websites you use regularly convey very important information through colours or images that do not convey the necessary information in voice. You will experience how, if you only have your ears to rely upon, you will "skim" with H and Shift+H to jump between headings on the page. You will experience the difference between an acceptable "click here" and a very confusing one.
Once you know one tool, everything else in accessibility makes sense. That one tool won't be enough. As you get deeper into accessibility, you will get into mobile and start expanding your test cases. But learning to use a screen reader is absolutely necessary if you want to start building more accessible sites or applications.
Colour matters, but it cannot be the only way you convey meaning
If we only look at accessibility through the eyes of blind and visually impaired people, we have to think in terms of a continuum, with what most people consider blind, which is quite rare, at one end, and people with colour blindness, trouble seeing low contrast, or trouble seeing small fonts throughout the continuum.
And so colour matters a lot, even for people on the spectrum of visual impairments. Certain colours do convey meaning. Green is generally "go," while red often conveys things like "delete" or "cancel." The issue only starts to become a big deal when you start thinking through points in the continuum of visual impairments.
As an example, consider people who have more trouble seeing low contrast. If you are going to use colour to convey meaning, you have to make sure that the contrast ratios are high. So, if you have a red button, first you should check the contrast of the red button against the background, and then you should check the contrast of the text colour against the red button colour.
Using text instead of, or with, an icon is very important as well. You will intuitively sense this as soon as you learn to use a screen reader. While screen readers are excellent at finding semantic HTML elements like buttons, if you only have an icon on it, it's not a great experience. If you have text or text plus an icon, it makes using a screen reader quite pleasant, actually.
So, don't entirely move away from colour because colour does communicate a lot of meaning. But be careful that all people can see the colour contrasts, think about how your colour choices would look to people with various forms of colour blindness, and be careful to convey meaning in text form as well as in colour. Learning to use a screen reader will make all of this intuitive.
Write semantic HTML
Back in the day, there was this idea called the semantic web. A lot of ideas from the semantic web are just standard parts of web content engineering now, and I will write other articles about that form of semantic meaning. But now I am only talking about semantic HTML.
If you want to instantly improve your front ends, use structural HTML elements, such as <header>, <nav>, <main>, <article>, and <footer> whenever possible, instead of generic <div> or <span> tags.
Using semantic HTML like this will tell screen readers exactly what kinds of content they are parsing and help expert screen reader users use all the key combinations they rely upon. Incidentally, if you ever get the chance to watch a very proficient screen reader user use applications, it is a lot like watching a very good StarCraft player in terms of sheer keyboarding speed.
Add alt text for images
If you write semantic HTML, you will use <img> elements to place images on your pages. Going back to something I talked about previously when I talked about colour, a big part of building accessible websites or applications is making sure that your content is available to everyone. It's great to have images on your site. But make sure that you have alt text on your images so that people who use screen readers can get the same content, meaning, or feeling that the image conveys.
Provide captions and transcripts for media
I could have actually combined this with the last one. Videos and audio are very big parts of the web today. But videos are best if you can see and hear normally, and while audio does not rely upon sight, it does rely upon hearing. Deaf and hearing-impaired people make up another large portion of the population, and so it's important to make sure that everyone can access all of your content.
Luckily, between captions and transcripts, almost everything that can be conveyed with video or audio can be conveyed through text. When you start getting into audio descriptions, visual context, diagrams and timing when relevant, you can get very close to providing equivalent experiences.It's also quite interesting: if any of you follow or have any interest in search engine optimization, you're likely starting to pick up on how much this list is starting to look like a basic how-to on building search-friendly websites.
Support full keyboard navigation
In my experience, supporting full keyboard navigation is the most difficult thing to teach. The tools are really easy, but it's very hard to teach the intent and theory behind it to people who are used to using a mouse or other type of pointer. And it makes sense. Building up muscle memory to use a mouse was so important that, if you used Windows in the 1990s, all I have to say is "jack in the box" and you will know exactly what I am talking about.
And so this is yet another part of this list that will only start making sense when you start using a screen reader regularly. You will likely go through phases with a screen reader, starting with using it to augment your regular use. Then you'll reach a point where you start using your keyboard more, and finally you may reach a point where you just use the keyboard, your screen reader, and no monitor. When you get there, you may notice a difference between how your eyes navigate through something you built and how your Tab key navigates you through it.
And then this stuff will make perfect sense. tabindex will eventually become second nature and :focus in CSS will become part of your muscle memory too. Testing your work with a screen reader and your eyes will make this all make sense.
Pay careful attention to your headings. Make sure they are clear and hierarchical.
I write about headings quite a lot and Siteimp's headings view was one of the first things I worked on and started getting use out of. Repeating myself here, this comes directly out of my own work with a screen reader, no monitor, and no mouse.
Most people don't read all of most articles. Instead, people skim and pick out the parts that are of interest to them. People who use screen readers are no different, though skimming can take a lot longer. So chances are, if you choose NVDA as your first screen reader of choice, the first major shortcut you will learn is H and Shift+H. Those key combinations will advance, with H, or move you backwards, with Shift+H, through headings. Chances are, that's how you will skim.
Later on, you might start using 1 through 6 on the keyboard as well. And then you will likely give up on using this regularly because holy cow, headings on the web are a complete mucking fess.
And so, learn to use headings properly, make sure that your headings tell a story, and make sure that if you only consider your headings, the structure of the article will be clear. As a bonus, this kind of outlining approach will turn you into a better writer.
Make sure all your links are clear and descriptive
I love writing this one because this is the one I have the most trouble with. There is a certain visual style on feature pages where you have cards with clickable titles, a descriptive paragraph, and a "click here to learn more" action in the card footer that leads to the same resource as the clickable title.
It's funny because it looks good and honestly doesn't even sound that distracting. But it comes from a really bad habit that I had in my earlier days of building front ends. I overused anchor text like "click here" or "this link" back in the day.
The issue comes again from screen readers, and I was not even aware of what a weird experience this provided until I started using NVDA regularly. Remember earlier when I said that, when you start getting into NVDA, the H and Shift+H key combination will likely be your first shortcut? K and Shift+K will likely be your second or third. You will use K to jump to the next link and Shift+K to jump to the previous. Then a whole army of "click here" links will remind you of a broken record. And then again, when a Siteimp scan, or whatever tool you use, returns that you have not been using descriptive link text, you will understand why it's important.
Make sure your forms are accessible and well labelled
This is another one of those great areas within HTML and accessibility where learning to use a screen reader will just make this click. But every form input field needs an associated label. You should make sure to group related form inputs together. Any error messages or validation problems should be clear and provide specific instructions on which input is the problem. And finally, required fields should be clearly labelled with text, not just colour.
Follow these rules , there'll be mad form responses to read.
Most drop-in accessibility overlays are complete garbage. See 1.
I won't go into too much detail here or name any of the products that really annoy me. But if you follow the space, you have read a lot of big accessibility promises that can be delivered with a JavaScript snippet. The spirit is noble, but in reality most of those overlays make screen readers go a little crazy. Because while the overlays can bolt accessibility on top of something, they cannot fix the underlying structures , and so the net experience is more like using two totally different applications in one window.
I understand the appeal, but you will be happier long term if you just don't.
Conclusion
The biggest thing I hope people take away from this list is that accessibility is not a bag of tricks you pull out when someone asks for it. It is a habit and a lifelong learning process. The more often you use a screen reader, test with a keyboard, write good headings, label forms, and think about how people actually move through your work, the more natural it all becomes but it really starts at learning to use the tools of accessibility. So if you take nothing else from this, pick one screen reader and start using it.
None of these tips will make an application accessible on their own. But they will make you better at spotting the things that are not working, and they will make the fixes feel less mysterious and grounded in experience. That is usually where the real improvement starts because you will start thinking in terms of why these things are important. They will become a habitual part of how you build instead of an audit you go through.
Start with one screen reader. Build with actual structure. Test the things you make. Then keep learning, because accessibility is a much bigger and more interesting field than most of us realize when we first start writing front ends.