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 globablly 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 , 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:

• Higher placements in search results, leading to increased website traffic.
• Better engagement rates, due to an improved user experience.
• Increased revenue, with 51% of consumers willing to pay more for products or services from accessible businesses.
• A 50% higher market performance than their competitors.

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:

1. 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.
2. Screen Magnifiers An assistive technology that magnifies the contents of a screen, reduces glare, and improves contrast between the text and background.
3. 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:

1. Uses a logical document structure

Structuring documents in the following way allows screen readers to accurately determine the regions of the webpage:

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 , for example:aria-labels

2. 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.

3. Has the correct heading structure

Headings provide useful labels for a webpage’s regions, and help to organise passages of text. For users of screen readers, headings are integral to understanding the relationship between pieces of content, and allow the page to be easily skimmed. With headings being so intrinsic to the organisational structure of a webpage, it’s important to respect the hierarchy of heading elements – the most important of which being <h1> and the least important being <h6>. Some good best practices are:

1. Have only one <h1> on the page. This should describe what the page is about, and ideally be placed just above the main content.
2. All following headings after the <h1> should appear in the correct hierarchy; for example a <h3> shouldn’t appear before a <h2>.
3. Avoid skipping heading ranks, for example a <h2> should not be followed by a <h4>.

4. Provides text alternatives for non-text content

When confronted with non-text content such as an <img> or <video>, a screen reader will read text from the element’s alt attribute. Screen readers will treat elements with a blank alt attribute (ie: alt="") as decorative items, so it’s important that any non-text content that is important to understanding the page has alt text that accurately describes the information or function it represents. The WCAG provides a helpful alt text decision tree that can be used to determine the type of text that should be entered in an element’s alt attribute.

5. Uses unique labels for components

Interactive components such as buttons, links and form fields must all have a unique label that reflects the function of the element; a label for an email address input for example might read “Enter your email address”. The process of assigning labels to components depends on the type of element used:

• Form elements – added via the <label> tag (with the for attribute of the label set to the id of the corresponding form element), or the aria-label attribute.
• Buttons and links – added via the element’s inner text, or the aria-label attribute.

Assigning descriptive labels to links is especially important, as a commonly used feature of screen reader software is to list of all the links on the page – thus allowing users to quickly find the information they need. One of the most frequent accessibility pitfalls that developers encounter is failing to provide unique, descriptive text for buttons and links rendered repeatedly, such as in a forloop. This issue often stems from modern web design practices; at Baggy, we frequently encounter designs for product listing pages that display each product's title and image, with a generic call-to-action link (e.g.,Shop Now) beneath each item. When rendering this markup in a loop it's tempting to use the same text for each link, but this approach results in impaired users hearing a repetitive and unhelpful "Shop Now. Shop Now. Shop Now."

Instead, developers should utilise CSS to create labels that read as unique to screen readers, but display as the same to non-impaired users. The following CSS class can be helpful here:

Unlike setting display: none;, which will hide an element from screen readers in addition to the regular site, the .visually-hidden class above will simply hide an element from view while still allowing it to be parsed by screen readers. This can be used in conjunction with <span> tags to generate unique labels like in the following example:

To non-impaired users the text in each of the links above will still read Shop Now, but users of screen readers will hear Shop The T Shirt Now, Shop The Sunglasses Now.

Conversely, we can hide elements from screen readers, but still display them on the regular site, using the role="" attribute – elements with role="presentation" will be treated by screen readers as for display purposes only, so their content will not be read. We might therefore change our example above to read:

This will result in users hearing Shop The T Shirt, Shop The Sunglasses, which is slightly less repetitive than before.

While it can often be tempting to create markup using generic elements such as <div> or <span> and rely purely on CSS to indicate visual hierarchy, this approach gives no indication of the content’s importance or relationship to users of screen readers. For this reason, writing semantic HTML must always be our first priority when turning a design into markup, with CSS used to augment our content rather than define it – you might even find it helpful to comment out your stylesheets as you write your HTML so that you can get a feel for how someone using a screen reader may interpret your website.

Using generic components is unavoidable in some cases; very few websites nowadays are just static documents, and sometimes there may not be a semantic element for the type of component we need to build – interactive content such as modals, carousels, menus and tabs require a combination of HTML, CSS and JavaScript to work properly. This type of dynamic content can be problematic for users of assistive technology, as the content of the webpage may be manipulated in a way that accessibility tools may not recognise. Consider the following HTML for a modal:

Screen readers wouldn’t interpret this as a modal, as there’s nothing to say here that the <div> tag is separate from the rest of the content. There also isn’t an association between the View Size Guide button and the <div>, and there’s no indication that the former should toggle the visibility of the latter. In short, there is no information in the markup that describes the form and function of the code.

We can fix this using ARIA (or Accessible Rich Internet Applications), which is a collection of attributes that describe the intended behaviour of HTML elements. ARIA allows non-semantic elements such as <div> and <span> to take on semantic meaning via three main types of attributes:

1. Roles

The role="" attribute describes the purpose of the element; in the previous section we looked at using role="presentation" to designate an element as being for aesthetic purposes only, and similarly we can use role="dialog" to tell screen readers that an element is a popup or modalwith content separate from the main document. It’s helpful to familiarise yourself with the full list of ARIA roles and refer back to this as you write your HTML, but the most commonly-used roles are:

• alert – Used for displaying form errors or other time-sensitive user information.
• dialog – For popups and modals
• feed – A list of <article> elements where new <article>s are added as the user scrolls; useful for blogs or product listing pages.
• menu – Commonly used for site navigation, but is used for any list of actions or functions that require complex functionality.
• presentation – Used to remove an element from assistive technologies. This shouldn’t be used with any element that can receive focus.
• tab – For tabbed content, used on the buttons that toggle each tabpanel
• tablist – The list of tabs
• tabpanel – The content of each tab

Although it’s possible to assign semantic roles such as form, img and input to non-semantic elements, it’s far better practice to use the semantic elements themselves – ultimately ARIA roles should bridge the gap between semantic elements and modern web components, rather than replace semantic elements entirely.

2. Properties

Property-related attributes specify an element's characteristics, such as whether they are draggable, require an element, or have an associated popup. Some common ARIA properties include:

• aria-controls – Commonly used on buttons to identify the element that is modified or adjusted when the button is clicked.
• aria-haspopup – This indicates that a popup will be triggeredwhen the element is clicked.
• aria-label – Used to provide an accessible name to interactive elements such as buttons, as we covered in the previous section.
• aria-labelledby – Similar to aria-label, this allows us to use another element's content as the accessible name.
• aria-live – Used to indicate that the content of the element will be dynamically updated, commonly used with feed roles.
• aria-modal – Indicates whether an element is a modal. This tells assistive technologies that the user's interaction is limited to only that section until it is dismissed, and that the windows underneath the current dialog are not part of the modal content.

3. States

States convey the current interaction state of an element, such as its visibility or whether it is enabled or disabled. Some common ARIA states include:

• aria-hidden – Used to show or hide elements from assistive technologies.
• aria-expanded – This indicates whether a controlled element is collapsed or expanded; this is useful for components such as menus dialogs, and accordions.
• aria-busy – Used in combination with the feed role and the aria-live property, this indicates whether a feed is currently being updated.

Returning to our modal example from before, we can use ARIA roles, states and properties to make the functionality of our modal more explicit, and strengthen the association between the modal and the button that controls it:

Here, we have aria-controls, aria-haspopup and aria-modal designating the functionality of our code, aria-labelledby describing what our code is, and aria-hidden indicating its current status.

As previously mentioned, using ARIA is by no means a substitute for using appropriate semantic elements; the first rule of ARIA, as specified by the WCAG, is that if you can use semantic HTML elements, then do so. The WCAG also advises against changing the native semantic of elements through the role attribute, for example adding role="tab" to a <h2> tag – in this context, you should wrap the <h2> in a generic container <div> and assign the role to that instead.

Many impaired users rely on keyboard-only navigation to move around a webpage, traditionally by using the Tab key; when Tab is pressed, the browser finds the next focusable element in the HTML and focuses this, and conversely pressing Shift+Tab finds the previous element. By default, only elements with interactive semantics can receive focus:

• Links (<a>)
• Buttons (<button>)
• Inputs (<input>)
• Selects (<select>)
• Textareas (<textarea>)

When building custom components with ARIA, we therefore need to add additional functionality to ensure that users can successfully navigate around our application. This can be achieved via the following methods:

1. The tabindex attribute

tabindex is a numerical attribute that allows us to control the focus order of elements; the higher the number, the higher the priority the element will be placed in the tab order. There are two types of values we can use here:

• Negative integers, eg: tabindex="-1" – This makes the element un-focusable, which is useful for disabled controls or hidden modals.
• Zero, eg: tabindex="0" – This replicates the default focus behaviour, where the element will receive focus in relation to its position in the document. For generic elements such as <div> and <span>, adding tabindex="0" makes the element focusable.

Although it's also possible to assign positive integers here, it's recommended to avoid this – elements with a positive tabindex are placed before the default interactive elements on the page, which makes it harder to manage the tab flow for other focusable elements.

2. Focus trapping

When the user opens a modal, keyboard navigation should be limited to the area within the modal element. Focus trapping is the practice of confining the keyboard focus within a modal or dialog until it is closed, preventing users from accidentally tabbing out of it. This is achieved using the browser’s native focus() method. To initially focus our modal, we need to add the following functionality into the method that opens the modal:

From there, we need to add some functionality to loop the focus so that pressing the Tab key will only focus on elements within the modal. We can do this by adding a listener to the keydown event:

One consideration here is that this won’t trap focus for users of the screen reader mode on iOS or Android; to achieve this, we need to modify our code further to set aria-hidden="true" on all elements that aren’t our modal. Setting aria-hidden="true" hides an element’s children from screen readers too, so we can optimise our code by only setting the attribute on elements that don’t contain our modal:

While the above code is a good catch-all solution, you’ll find it beneficial to adapt this to better fit your document structure; reducing the number of DOM manipulations can optimise site performance, so it’s a good idea to target the hidden elements more efficiently based on the position of your modal in relation to the document.

A final consideration when writing accessible JavaScript is listening for mouse-specific events, such as mouseover and mouseout. Functionality that runs in response to these events will not be accessible via keyboard or voice controls, so it’s important to also listen for events that are more device-independent such as onfocus and onblur:

The exception to this is the click event which, despite its name, isn’t actually mouse-dependent as browsers will usually activate this when the Enter key is pressed on the currently focussed element. It’s therefore important to ensure that any non-interactive element responding to the click event has tabindex="0" set, so that this can be focussed by assistive technologies.

A common feature of assistive software, particularly with accessibility plugins, is to override a webpage’s CSS with their own custom styles; this might allow visually-impaired users to make font sizes bigger, or modify the text and background colours to create a higher contrast.

We therefore need to make sure that our designs adapt to these use-cases by using scalable units such as em, rem and percentage values to size and position our elements – this will ensure that the page scales in relation to the font size, thus preserving the whitespace and visual relationship between elements. Absolute units such as px, on the other hand, may not respond well to user preferences and should be used only for more precise positioning.

rem units in particular offer a number of accessibility advantages, as they scale based on a single root font size; sizing and positioning elements using rem means that impaired users only need to change a single value to proportionally adjust the entire layout.

While developers shoulder most of the responsibility for creating accessible websites, there are a number of ways web designers can facilitate this before the development stage begins.

Approximately 300 million people worldwide have colour blindness – a condition that makes it difficult to differentiate between certain hues. The WCAG contains dozens of success criteria for using colour on webpages, but the main things to be aware of are as follows:

1. Create a strong contrast between the text and background Users with low vision or colour blindness benefit from text that firmly stands out against the background. Tools such as this contrast checker can help you build colour palettes that meet the WCAG’s recommended contrast ratio of 4.5:1 for normal text and 3:1 for large text.
2. Don’t convey meaning with colour It’s best to avoid relying solely on colour to convey information, such as using red to indicate an error; in these instances, the WCAG advises to include additional visual cues such as text, icons or underlines. This will ensure that all users will be able to understand the content, regardless of their colour perception.

Although impaired users may manually override a webpage’s default font size to make it easier to read, it’s generally agreed that 16px is a good baseline font size for the main body text to ensure legibility.

While there are no official guidelines on sizing and spacing, designing on an 8px grid (ie: sizing and spacing every UI element in increments of 8px) is a commonly-agreed best practice for a number of reasons:

1. rem units, which allow web designs to scale proportionally in response to changing font or screen sizes, are in multiples of 16, so creating sizes and spacing in multiples of 8 converts seamlessly.
2. The majority of devices have screen sizes that are multiples of 8; iPads for example are 1024px wide, and large laptops are usually 1400px. Designing on an 8px grid therefore gives you the best responsive results.

A key priority is ensuring interactive elements are easily clickable through sensible sizing and ample spacing; as a general rule, interactive elements such as buttons, links and form fields should be no smaller in width or height than 40px, which is the average size of a touch point on touch screen devices. With that being said, it’s a good idea to build frequent prototypes throughout the design process to ensure optimal usability.

On the subject of interactive elements, it’s important that users can easily distinguish these from the rest of the content. The WCAG advises designers to implement a consistent style for elements such as buttons and links that’s distinct from non-interactive elements such as headings or paragraphs, for example adding an underline to links or a border to buttons.

State-specific styles that change the appearance of interactive elements in response to user events, such as hovering or focusing, are absolutely integral to helping users understand when an element is being interacted with – particularly for those navigating the website via keyboard. In general, you should try to design for the following states:

• Buttons and links

  • Default
  • Hover
  • Clicked
  • Disabled
  • Focused
• Text inputs

  • Default
  • Hover
  • Clicked
  • Disabled
  • Focused
• Radio inputs and checkboxes

  • Default
  • Hover
  • Clicked
  • Disabled
  • Focused

It can also be useful to introduce slight variations on the default style for interactive elements, as this can help users navigate the content more easily; when two CTA buttons are shown next to each other on the page, for example, displaying one in a different style can help users distinguish the different pathways more easily, and give some indication of their importance.

Following the correct document structure is, as we previously covered, paramount to helping users of screen readers easily navigate the content and find the information they need, but ultimately this also benefits users who don’t have accessibility considerations – having a distinct path to information and actions helps users digest content, thus driving engagement.

There are a few ways we can strengthen the hierarchy of our web content:

1. Include a heading for each section Adding a heading at the top of each section aids user cognition and makes the content easier to digest, particularly for users having the page read out to them by an assistive device.
2. Attach labels to interactive elements Elements such as form fields must have an associated label that should be placed above or to the left of the element, explaining to users what content needs to be entered in the field. While including a placeholder for such elements can be helpful, using this as a substitute for a separate label can often create a poor user experience due to the text disappearing when the user focusses the content, which can be frustrating to those using keyboard navigation to traverse the page.

Focusing on simplicity and clarity in your design choices can enhance comprehension and navigation for all users, especially those with cognitive impairments. The goal of any website is to convey information as quickly and efficiently as possible, so keeping things simple and relying on established UX patterns to make your site as intuitive as possible is always a good idea – remember, there’s no need to reinvent the wheel!

Some good tips for simplifying your designs include:

1. Ensure consistency Using a consistent design across elements such as icons, navigation and interactive elements helps to establish a sense of familiarity, helping users understand the content of the page by reducing the time and cognitive load required to learn and navigate a new website.
2. Avoid unnecessary visual elements Visual clutter can disrupt the document hierarchy and make it harder for users to determine the most important information. While decorative elements can convey brand personality, it’s best to use these sparingly to ensure that the primary information is not overshadowed.
3. Make navigation easy The principle of least effort states that users will make choices or take action requiring the least amount of energy. If a product is too complicated or there’s a steep learning curve, users are less likely to use it.