Weaving an Accessible Web
Considerations for even the newest coders in HTML
The web is for everybody. (And maybe some smart pets?) The UN has even decreed that the internet is a human right. If you are reading this article, you most likely use the internet on a daily, if not hourly or continuous basis. There is very little that cannot be enhanced or improved in some way through the help of the internet. Perhaps it’s comparison shopping, or looking up the weather before an outdoor trip, or finding a job or apartment. Having use of the internet gives us an advantage we didn’t have without it.
“The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location, or ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.”
So how do we make sure that everyone can use the internet? Web accessibility plays a large role. Over a quarter of people in the United States have some type of disability, and that number rises as people age. Even more people will be affected by temporary disability in their lifetime, such as a result of an accident or surgery recovery. Even if you think a site is “fine” and works for “most people” now, you’ll probably wish more apps were made for aging eyes or more friendly to those with repetitive stress injury or arthritis sooner than you think! Accessibility is not limited to addressing disabilities, and includes making sites for those with limited resources (e.g. not the newest iPhone on high speed WiFi).
Here are a few examples of considerations for website accessibility:
- Does this page convey information on a screen reader for those who need or prefer audio?
- Are these colors contrasted enough for bright sunlight, color blindness, or other contrast sensivity conditions?
- Can this site be navigated with a keyboard without a mouse? Vice versa?
- Can an older machine on slower internet load this site in a useful amount of time?
- Is the text easy to understand? How about for a non-native speaker? Have you considered a translation option?
Though we should strive to approach 100% accessibility, it is both easy and impossible to fully achieve. There are entire legal teams involved in keeping resources compliant, and even the easy-to-use a11y project checklist has over 50 items to consider based on W3C’s Web Content Accessibility Guidelines (WCAG). But not to let “perfect be the enemy of good”, there are things even someone just starting in their journey as a web developer (as I am!) can be aware of.
Semantic HTML Tags for Containers
In theory, you could get away with constructing sites with<div> and <span> elements all day (as we did pre-HTML5), maybe adding some classes to assist with styling and help you remember what they are for, like class="header" for an element containing a logo or class="nav" for an element containing helpful links to main sections of the site. But ultimately, those tags are not very descriptive. Is this div an article? Or a menu bar? When you sketch out the layout of your room, you may draw a rectangle to represent a couch, but without a good label, it could also be a table, or a bathtub. Instead, you could use semantic element tags, like <header>, <nav>, and <main>, making it easier for both the developer and user to get a sense of what information is where on the page. They convey meaning to the content within them, as described in the docs. They were introduced in 2014 with HTML5, so if you learned HTML before that and haven’t picked it up since, it’s definitely worth a skim!
Inline Semantic HTML Elements
The semantics don’t stop at naming containers and sections of the page. You can give context and indicate if something is a <time> or <address>, highlighted text with <mark>, or a <code> block. These tags can make it easier for someone to quickly find contact or event information, or know that some unusual combination of words and sounds is actually code.
There are two pairs of tags that often get interchanged, <i> &<em> (which will usually lead to italicized text) and <b> & <strong> (which will lead to bolded text). However, they have different meanings. <i> and <b> are used just for styling while <em> and <strong>, as their names may suggest, are meant to assign emphasis or importance to the text, and will be read accordingly by screen readers. If the effect you are looking for is merely cosmetic, try to use styling and not the semantic tags.
Here’s a reference for the tags again. Read them through and think about using them on your next mock-up!
Form Labels for Clickability
Forms are everywhere. Every time I learn a new part of web development, there’s always some forms topic waiting, much to my chagrin. But there’s a reason for that. Forms are a big part of a user’s experience, like signing up for an account, entering payment details, or searching for information. If you’ve ever made one you probably know about the <label> tag. If bound properly to the input field, a user can click anywhere on the label, and that field will come into focus to be typed in. This is helpful for those who may have trouble using their mouse steadily, or anyone who’s ever fumbled on their smartphone, blaming their “fat fingers”.
Here’s a quick demo: try to check all the boxes!
Tabindex for Navigating
Elements can be given a tabindex attribute to determine which elements and in what order they receive focus when you press the Tab key. Forms, buttons, and links are automatically put into this list, but you can also manually assign and order them as makes sense in the design of your site. Try pressing tab on the next site you’re on…you might find yourself taking advantage of it on well-designed sites in the future!
Alt Text for Images
All images should be provided with alt text which will be displayed if the image doesn’t load (like in areas with unreliable internet), or for screen readers to pick up. As these are made to serve as stand-ins for the photos, be sure to be descriptive. For example in this photo:
Okay alt text: “Cat”
Better: “Black cat with blue collar”
Maybe even better: “Black cat with yellow eyes sitting in a lap wearing a blue inflatable recovery collar looking up at the camera”
Using Text instead of Screenshots
If you are including examples of text, like code snippets for a coding blog, try to use a text-based medium over a screenshot whenever possible. This means that a screen reader can handle the code or someone curious can copy and paste it. Medium uses Embedly, which allows for easy integration with other apps. So in addition to using a code block (activated using 3 backticks in a new line — ```), you can easily embed code from a Github gist or sites like codepen.io (used above), JSfiddle, and Scrimba. As a bonus, these embeds also more interactive!
Utilize the Internet You Know and Love
Ready to move on from the basics? Search around! Here some tools you can use as well to test out sites and accessibility:
- Funkify, a browser extension that allows to you simulate various disabilities and conditions, including those based on vision, cognition, motor function, and dyslexia
- Can I Use…, which have tables which show what front end features are supported by which browsers. For example, here’s the compatibility for the CSS attribute
position: sticky. (Spoiler, Internet Explorer doesn’t support it. Or a lot of things. Seriously, stop using Internet Explorer. Tell other people to stop too if they have a choice.) - Lighthouse, an open source automated tool to check and rate your website on a variety of criteria, which you can use right in Chrome DevTools!
Fun note on the term “a11y” used earlier — it’s a numeronym that stands for accessibility! There are 11 letters in between “a” and “y” and it conveniently spells a relevant word.
I know these tips don’t cover much, and I personally already struggle to remember to stay on top of these, but we code, we live, and we learn. Let me know of any of the many corrections I should make!
