Web accessibility, or a11y, is the idea that everyone in the world should have the same access to information and services on the web regardless of impairment or disability – be this visual, physical, auditory or cognitive. The core principles of a11y are outlined in the Web Content Accessibility Guidelines (WCAG), an internationally-recognised set of standards and recommendations designed to help digital services make their content more perceivable, operable and understandable to users with impairments.
At the time of writing, nearly 1.3 billion people worldwide (roughly 16% of the world’s population) are living with a significant disability, yet a staggering 98% of websites globally are currently failing to meet the criteria outlined in the WCAG. Alarmingly, to those who access the web through assistive technologies such as screen readers, magnification tools and speech recognition software, the vast majority of websites are unusable to some degree.
Poor accessibility isn’t just a problem for users with disabilities; anyone who has struggled to close a popup can attest to how frustrating it can be when trying to use a website with no clear navigation or interaction points, so it’s unsurprising that businesses who fail to offer an accessible user experience end up losing out. In the UK alone inaccessible websites cost retailers £17.1 billion in lost revenue in 2019, but this isn’t the only reason businesses should be prioritising accessibility – since 2018, 82% of the top 500 e-commerce retailers have faced accessibility-related lawsuits for lacking essential features for screen reader users such as alternative text, accessible drop-down menus, and keyboard navigation. Conversely, businesses who do make the effort to make their user experience accessible reap the following rewards:
Ultimately, prioritising accessibility in web development is not just a smart business move, but a moral responsibility; accessible websites provide equal opportunities that the physical world, where impaired individuals face obstacles in transportation, architecture, education and employment, often fails to offer. Our commitment to accessibility demonstrates care for our audience, thus fostering meaningful connections and building loyal user bases who value and depend on our websites – which is why at Baggy, we always develop with accessibility at the core of our practice, rather than an afterthought.
To understand how to provide an accessible user experience, we first need to appreciate how impaired users interact with the web.
Some common accessibility tools include:
Screen Readers
Otherwise known as Text-To-Speech engines, these translate on-screen information into audio, thus making the web accessible to those with visual impairments.
Screen Magnifiers
An assistive technology that magnifies the contents of a screen, reduces glare, and improves contrast between the text and background.
Mouse-Free Navigation
Using keyboard commands (or sometimes even facial expressions!) to move around and interact with things on the screen.
While these tools greatly assist those with impairments, no assistive technology is flawless, so we developers must build our sites to maximise their effectiveness; without meaningful alt text on images, even the best screen reader can't convey the image's content to blind users, and similarly if call-to-action buttons aren't well-spaced, even those using the most advanced hands-free mouse may struggle with accidental clicks.
With so many assistive tools available, the concept of writing code that can adapt to every technology can be daunting. Fortunately, the guidance of the WCAG can be condensed into the following core principles:
A website is fundamentally a document – it's composed of headings, paragraphs, diagrams, and small interactive elements like buttons and links. Users of screen readers navigate websites by skimming these headings, regions, or links to identify items of interest, and will expect the reader to announce the name, role, and value of each component on the page. To facilitate this, we should ensure our HTML code adheres to these best practices:
Uses a logical document structure
Structuring documents in the following way allows screen readers to accurately determine the regions of the webpage:
<head>
<!-- A clear and specific title for the page -->
<title></title>
</head>
<body>
<!-- Site-wide information such as the logo, navigation and search functionality -->
<header>
<!-- A nav menu -->
<nav></nav>
</header>
<!-- The main content of the page -->
<main></main>
<!-- Site-wide information such as copyright information, privacy statements, or disclaimers -->
<footer></footer>
</body>
Landmark regions such as <header>, <nav>, <main> and <footer> help screen readers identify the primary content of the page, and allow webpages to be skimmed more efficiently.
Sometimes you may have more than one landmark element of the same type, for example a <nav> for the main site and a <nav> within a particular section. In these situations, you can differentiate the regions using headings or aria-labels, for example:
<!-- Using a heading -->
<nav aria-labelledby="regionheading">
<h2 id="regionheading">On this Page</h2>
</nav>
<!-- Using aria-label -->
<nav aria-label="On this Page"></nav>
Employs appropriate semantic elements
Semantic HTML elements are used to define the meaning of the content they contain; a <h1> tag for example defines a heading, and a <section> defines a section of the page. Using semantic elements not only creates more meaningful content to assistive technologies, but also helps impaired users navigate the page more easily via special browsing modes that simple elements like <div> and <span> lack – such as jumping to next heading, table cell or list item via the TAB key.
Some examples of semantic elements include:
<section> – A general region of a webpage, used to group content thematically.<ul> and <ol> – For unordered and ordered lists, respectively.<blockquote> – For quotes.<figure> – For diagrams, images, lists, tables, or any kind of illustration that needs to be pulled out from the main content. It’s recommended to accompany this with a <figcaption> to describe the content of the figure.<img> – For images.<table> – For tables.<strong> – For bold text.When coding HTML, it’s helpful to refer to the full list of HTML elements to determine which element would best fit the content you’re trying to convey.