Web Accessibility

This chapter contains information regarding web accessibility, drafted akin to a primer document on the subject. Parts of this chapter will be covered during the HTML Recap & Best Practises teaching so treat this as an additional starting point for your knowledge. Web accessibility is a mounting topic with significant affects on many people's lives

Accessibility: Why Bother?

Did you know that 26% of adults in the US have some form of disability? Whether this be a mobility, cognitive or sensory impairment, this makes up the vast number of 61 million people who face some form of difficulty in their daily life. If we extrapolate this statistic globally, this makes an incredible number of people that, through our lack care, we may upset at best or lose the attention of at worst. Not only that, failing to provide proper accessibility to all users is a legal issue, alongside a moral one.

It is our job as web developers to make sure that our sites, our products, are accessible to all, regardless of these difficulties. This is especially true when you consider that at its core, the web is entirely accessible to all users. Semantic HTML elements provide many of the tools for us to succeed in our mission; It is only when we add on layers of CSS and JavaScript, scripting, and templating languages that we begin to deviate away from this accessible base.

An Introduction

In this document I hope to highlight some of the small changes we can make which could make a big impact for our users. It is by no means intended to be exhaustive, but rather to help begin your learning process in this area which is often overlooked.

As you move forwards, it may be that you find work within a team of developers with a separate designer, where it is difficult to speak up about issues which may be arising. However, remember that it is through finding your own voice and acting as an ambassador for any minority that affects the most change.

The best piece of advice I can give for becoming a more conscientious developer is to always be open to learning. Spend some time with the MDN documentation for an element you are less familiar with or read some articles about emergent technology. Figure out why areas may be progressing, form your own opinions, and bolster your breadth of knowledge.

Notes

WCAG

https://www.w3.org/WAI/standards-guidelines/wcag/

Web Content Accessibility Guidelines. The published web accessibility guidelines. Maintained in 1999 the World Wide Web Consortium (W3C), the main international standards organisation for the Internet. The current most complete documentation is WCAG 2, however WCAG 3 is in production and the draft is available online. I may link to either of these documents.

WCAG Compliance Levels

There are different levels of compliance within the WCAG documentation ranging from A to AAA, with AAA being the highest level. Different sections and subsections within the published documents have different associated levels. If something is of A-level compliance, then it is something that should be included on all sites as a minimum.

Semantic HTML Element

An HTML element, such as a <button> or <h1> element, which provides some context for how it is being used within its designation. Such elements may include functionality “under the hood” which is not always apparent with general use. (For instance, <button> elements are triggerable on pressing [space] without the need for additional code)

`.sr-only`

https://css-tricks.com/inclusively-hidden/

Sometimes you may want to add in some content, such as a header or paragraph, to your webpage which is not visible but is available to a screen reader. The addition of a screen reader-only class to your CSS is a robust, efficient means to garner this effect owing to its reusability. The inclusion of multiple means to visually hide the content can also be included to ensure consistency across browsers.

DOM

Document Object Model. The tree-like structure which defines the structure of your webpage. Split primarily into the <head> and <body> elements, the DOM is a code-representation of your site and can be viewed in the browsers inspect tool.

ARIA

https://w3c.github.io/using-aria/

Accessible Rich Internet Applications (ARIA) is a set of attributes used to define ways of making the web more accessible to people with varying disabilities. Aria attributes are generally prefixed as such and aim to provide additional information to users that may miss the same information through different means, such as a user with low vision missing visual cues.

Note that developers should opt to use the correct semantic element over the use of ARIA attributes in the interest of keeping your code lean and correct. Often when a developer looks to include certain aria attributes, they are mimicking the functionality which may already be included within another element.

A11Y is the numeronym or alphanumeric acronym for “accessibility”, where the first and last letter reflect that of the word and the number represents the additional missing letters. Many businesses use the term within their own product names or catchlines to associate themselves with accessibility.

Visual

Visual impairments are often what come to mind at the mention of disability. It’s easy to imagine how your own sight may falter, and hence relate to another. However, it is not always obvious how the requirements of a non-sighted user may manifest and how visual design begets requirements which overlap with other disabilities.

Text Sizing

The size of text on a webpage, regardless of design, should be legible without the need for zoom. There are no strict thresholds defined by WCAG2 however, including figure captions, most websites will not go below 12px. The default of many browsers is 1rem, which is a variable sizing unit most often corresponding to 16px.

Additionally, the size of all text on a webpage should be able to be independently increased by the user up to 200% without loss of content nor functionality to the user.

10px	12px	16px	20px
The quick brown fox jumps over the lazy dog	The quick brown fox jumps over the lazy dog	The quick brown fox...	The quick brown fox...

Figure 1: Examples of different text sizes with their sizes labelled

Colour Contrast

https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html https://webaim.org/resources/contrastchecker/

Legibility of content depends not only on the size of the text but also on the contrast between the text colour and background. The thresholds for contrast do, however, additionally depend on the size of the text themselves.

WebAIM is company which has published articles regarding web accessibility and delivers training courses. They have a nice contrast checker with a neat explanation.

Fails to meet requirements	AA compliant (Normal Text)	AAA compliant (Normal Text)	AA compliant (Large Text)
Colour contrast (approx. 2:1)

Figure 2: Examples of different colour contrast levels for text with their approximate contrast ratio provided alongside. Note the different requirements for Normal (12px) and Large text (16px).

Use of Colour as the Sole Indicator

https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-without-color.html

A change in colour, whether this be on hover/focus or as part of a separate notification, should never be the only indicator of a change. Users of your site with colour blindness or achromatopsia may fail to recognise a change and hence struggle to use your site.

Use of text/box-shadows or occasionally simple animations can help many users understand where and how to use your site, in addition to the retention of on-focus boxes (below).

Figure 3: Examples of some simple styling changes which can be made on hover/focus for a button element which are not solely dependent on colour—Left: simple button. Centre: addition of box-shadow and larger border. Right: larger, dashed border

Focus outlines

https://www.w3.org/WAI/WCAG21/Understanding/focus-visible.html

Modern browsers include on-focus styling for when a keyboard user tabs to targetable content on your webpage. This focus styling should never be removed entirely but may be replaced. The default styling (on Chrome) uses a static blue colour which may cause visibility issues depending on the sites’ design and colour palette. From this issue or from simple design considerations, you may want to change the default styling, making it more visible or stylish. Remember however that the colour contrast point from above applies here and that accessibility takes priority over aesthetics.

Figure 4: Default on-focus styling (Chrome) can be seen surrounding the Technologies link

Auto-play content can be paused/stopped

https://www.w3.org/WAI/WCAG21/Understanding/pause-stop-hide.html

This encompasses all content which auto-plays on page load, including CSS animations. Moving content can be heavily distracting or even nauseating for some users and so you should provide obvious means for the content to be paused, stopped, or hidden, such as a clear media pause button. Such functionality may be provided on hover/focus.

Flashing or Blinking Content

https://www.w3.org/WAI/WCAG21/Understanding/pause-stop-hide.html#dfn-blinking

Flashing and blinking content pose as serious issues for users with epilepsy or that prefer reduced motion as above. W3C define strict parameters for how much any content may blink with the general threshold being no more than three times a second. Note however that the apparent visual field is taken into consideration alongside the change of colour/contrast.

Prefers-reduced-motion

https://www.w3.org/WAI/WCAG21/Techniques/css/C39

The use of CSS media queries can be helpful in making your website accessible to users who may find animated content nauseating or even painful. By checking the users’ set system preferences, you can automatically pause moving content on accessing the webpage and can even override any more complicated movement effects (e.g. Parallax effects)

@media (prefers-reduced-motion: reduce) {

    html:focus-within {
        scroll-behaviour: auto;
    }

    *,
    *::before,
    *::after {
        animation-duration: 0.01ms !important;
        animation-iteration-count: 1 !important;
        scroll-behaviour: auto !important;
        transition-duration: 0.01ms !important;
    }

}

Figure 5: CSS code snippet showing an example of a prefers-reduced-motion “nuke” which aims to aggressively disable all animations on your webpage

Labels

https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html

Labels don’t just look nice, they provide a function, especially to forms. The inclusion of static, unambiguous labels for form fields helps not only your users but also yourself, owing to more concise and correct information being provided by your users. Correct inputs on first try also removes the requirement of having to navigate the form multiple times, which may be cumbersome for some users, especially if there are many fields.

Placeholder text can be used to provide some information to the user before entering text into a field, however that information should not be required to input correctly. For instance, if a character limit is imposed, the placeholder text should ideally not be the only indication of this.

Implicit Labelling

Label elements can be associated to an element or input field by wrapping them within <label> elements. The label text is included within the elements before the content.

Explicit Labelling

Label elements can also be defined separately and then referred to using the for and id attributes. Here, the label text again sits within the <label> element and the for attribute is written to point towards the relevant element’s id. Some voice dictation software doesn’t support the use of implicit labelling so explicit labelling is encouraged.

Touch sizes

https://www.w3.org/WAI/WCAG21/Understanding/target-size.html

Interacting with content can be frustrating on mobile if the sizing of the target is too small. A guideline minimum of 44 x 44 px is quoted by the WCAG documentation with a suggestion for frequently used targets to be larger. The most common exception to this guideline is inline link texts, which don’t have a sizing suggestion imposed.

Larger interactable bounds help reduce accidental activations of your function. Targets should also be positioned away from the extreme bounds of the page for ease of interacting.

Simple UX

https://www.w3.org/WAI/perspective-videos/layout/

This point is general and encompasses many parts of the WCAG documentation. Most webpages will follow the same structure of “Header, Main Content, Footer” which means that regardless of whether you have visited a website before, you have a good idea of where to find the information you are looking for already. Going against this trend is okay, however it is incredibly important to collect your content within groups which are easily identifiable, suitably separated and, often, labelled to create visual signposts for your user.

This is extremely important for both people with cognitive disabilities and those with low vision who use screen magnification on webpages. If it is not clear which content relates to each other or where you are to progress to next, users can become frustrated, lost, or overwhelmed, which may cause them to leave your site.

Signposting important functionality such as login functionality will benefit all users.

Zoom

https://www.w3.org/WAI/WCAG21/Understanding/reflow.html

Related to the independent increasing of text size, the use of the browsers’ inbuilt zoom function helps many people with lower vision consume content on your sight. Content should be able to be zoomed by up to 400% without triggering the need for two-dimensional scrolling on the text content. The webpage content should hence fall within one column on increasing the zoom level, with the text size increasing to an ideal minimum of 200% at each breakpoint.

This does not apply on content where retention of the aspect ratio is imperative to understanding the content, such as images or videos. While such an example is outside the scope of the recommendations, and hence horizontal scrolling could be considered compliant on a site with a non-scaling image, it is still best practise to scale images inversely with increasing zoom level to always contain the page within the viewport.

Contextual

While we create new and exciting websites, it can feel cumbersome to realise best practises, especially when you yourself don’t visually recognise the changes you are making. However, when you are next reaching for a <div> element to apply an onclick attribute to, remember that HTML elements themselves are more than meets the eye.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5820628/

A medical journal article from 2017 concluded that a vast 253 million people suffer globally from at least moderate visual impairment. While they did indicate that this global percentage has decreased since the 1990s (4.58% down to 3.38%), this is still over 3% of the global population which strictly needs some level of treatment or assistance to live easily, independently.

Screen readers are assistive technologies created specifically to help bolster this independence. From webpages, to documents and operating system menus, screen readers read aloud digital content sequentially, controlled through keyboard input, and often at speeds far greater than a lay persons’ listening comprehension. But such systems are not magical. Screen readers can only provide what we first provide them ourselves. Using the correct semantic HTML elements and providing accessibility signposts (such as specifying the role attribute) is the minimum we as developers can do to make the web accessible for all.

Page Structure

https://www.w3.org/WAI/tutorials/page-structure/

As introduced within the Simple UX section, the layout of your page will most commonly fall into the structure of “Header, Main Content, Footer”. When creating a webpage, you should ensure that the page is as closely reflected in the DOM as possible, making a cohesive story between moving down through the webpage visually with how screen readers will interact with the DOM. But placing elements sequentially isn’t all that we can do to organise our webpage.

Depending on how a screen reader is set up and the technical capabilities of the user, the program may either progress through the page, through every element in turn, or instead may first scan the page for significant markers, such as headings, before compiling a list of such elements and then creating a more natural navigational system for the user.

For both sets, however more meaningfully for the latter, formal organisation of information on your webpage will significantly improve their experience. As discussed more specifically in the following sections, headings and selecting the correct HTML elements takes steps towards creating a cohesive webpage. But we can also organise our content at a higher level, introducing <header>, <nav> and <footer> elements to create sections in our code. This also has the benefit of making your code easier to parse for yourself in the future or anyone else who may be working on it later.

The <header> should include introductory content for you page which is replicated across each page and may include a logo image. The <nav> should include a list of links, commonly within an <ol> or <ul> element for the key navigational points of the page. The <footer> element is partnered to the <nav> but holds less significant links.

Sections and Articles

You may also consider the use of <section> elements if there is not already a specific element you can use to describe the region. If the encompassed content makes sense as standalone piece, then consider using an <article> element.

Heading Elements

https://www.w3.org/TR/WCAG20-TECHS/H69.html

Heading elements, generally ranging from <h1> to <h6> are a commonly misunderstood set of elements. By default, the sizing of heading elements varies inversely with the title number, and it is from this visual cue that people often derive their meaning. But heading elements are hierarchical and exist to provide organisation to data, thus structural information, not decoration.

A page will generally have a singular <h1> element at the top of the page or following the navigation component, defining the whole of the content found on the page. Each subsequent heading will increase in number with decreasing level of scope. This means that headings of equal number are at the same level of scope but cover different topics. Following down through a set of headings, you can consider each heading as the parent of those that follow of greater number; Each <h4> belongs to the next above <h3> which is a sub-section of the parent <h2> for example.

It can be difficult to envision how these relationships manifest on a webpage. The following diagrams should help demonstrate how to set up your markup.

(top) Figure 6: Heading elements within a webpage follow a strict hierarchy. Levels are not skipped

(bottom) Figure 7: Example of use of heading elements, specifying sections and subsections

When organised properly, technical screen-reader users will find it significantly easier to navigate your webpage: jumping through the series of headings that are applicable to themselves to get to the content they are looking for efficiently. Because of this, it is worth considering the addition of headings which make use of a screen-reader only class. This provides the directions a screen reader user may require without changing your overall design.

Aria-current

Aria-current is an attribute which is used within the navigation component to specify which page the user is currently on. It is specified as aria-current=”page”. This is especially useful for screen-reader users when the earliest content on a page does not fully represent the content of the page. The use of a simple if statement on each nav link is enough to include this attribute, comparing the current URL to the href of the anchor element.

Safari List Discrepancy

There is some inconsistency with the Safari browser regarding the handling of lists which can affect how a screen reader reads the page. When using a <ul> element and if you set list-style-type: none, such as is often the case with key navigation elements, then you must add a role attribute for role=“list”, otherwise a screen reader will not recognise it as such. This is distinct from the other major browsers however is intended behaviour and thus is unlikely to be changed.

Skip Links

https://www.w3.org/WAI/WCAG21/Understanding/bypass-blocks

https://webaim.org/techniques/skipnav/

Content repeated across pages can become tiring for keyboard users to move through, especially if you have many navigation links within your introductory content. Skip links are an example of bypass block functionality: interactable content provided to streamline navigation within a large webpage, generally taking the user to an element with a specified id with use of an anchor <a> element. Skip links are appended to the beginning of the document and on activation skip the repeated header and navigation elements. This cuts down the number of key presses required for a keyboard user to get the main content significantly, ensuring a better experience on the site.

Image Alt-Text Attributes

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img

https://www.w3.org/WAI/tutorials/images/decision-tree/

Images can be both fun and functional. We use them to display information, as backgrounds, as logos for buttons or even to provide context for adjoining pieces of data. Alt-text is the text provided alternatively if the user is unable to view the image. “But what should the text describe?” You may ask, which can be difficult to answer as ultimately, it depends. Context is paramount to defining how we should write our alt-text, regarding both what the image itself portrays and the meaning behind its choice.

Ask yourself first “Why is this image here?” and then “Is this information also specified elsewhere?”. In most cases where the information is additional to the greater content, such as when included in figure captions or adjoining paragraphs, you don’t need to worry about alt-text. This, however, doesn’t mean that you should not define it at all. Missing alt-text says to a screen-reader that you failed to consider its definition and will most likely read out the entirety of an images’ URL instead. Placing an empty alt attribute (alt=””) will instead specify to the screen reader that the image is entirely decorative or otherwise surplus to understanding the content of the webpage.

On the other hand, when the image alone exists to provide certain information, the alt-text attribute should be written to provide what may be missed. Alt-text is an accessibility tool and it is best to use your own judgement as how to concisely describe the information which may be needed. Remember to consider the “Why?” of the image and not just the “What?”. The W3 have a handy flow diagram to help you understand when and how you should write your alt-text.

SVGs

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attribute

If you are using <svg> elements as images on your webpage then specify the role as role=“img” and use the aria-label attribute in place of alt-text.

Interactive HTML Elements

https://www.w3.org/TR/wai-aria/#aria-label

Expanding on the area of semantic HTML elements, interactive elements each hold their own meaning and adjoined functionality. The following list should help briefly outline the most common interactive elements and their proper use-case.

`<button>`

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button

Button elements are interactive portals on a webpage which invoke an attached on-click function. By default, they are focusable through use of [tab] and are also activatable by use of [space] and [enter]. They will also submit a parent form on activation. Buttons should have clear, accessible text which describes their function.

`<a>`

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a

Anchor elements serve as connection points within your webpage, connecting other pages, files, email addresses or locations on the same site. These elements use the href attribute to specify their destination. Specifying an aria-label or aria-describedby attribute can help screen-reader users gain information they would otherwise perhaps miss from the visual context of the page.

Such an attribute can also be used to indicate where the anchor element will lead the user on activation, and hence improve the user experience. Note however that the aria-label will replace the accessible text written within the anchor element and so you may need to re-specify some information. For instance, an anchor element which reads “read more” could be labelled as “read more about our product – red shoes”, providing the associated information sighted users would gain from a quick glance at a title—an action which may be far slower for a user with poorer sight.

It should also be mentioned that avoiding general link text such as “read more”, “learn more” or “click here” is best practise and that where possible the link text should be descriptive of the destination. Imagine displaying a list of your pages’ links and descriptions as a list which makes sense on its own.

`<input>`

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input

Input elements are used for free-form user input, the style and function of which varies with the type attribute. The default of type=”text” is simply a text box which users can type into, however, more complex input methods such as image uploading, colour pickers or multiple-choice selectors are all included behind different types.

Inclusion of static labels significantly improves the user experience for sighted users, while the coupling of fields to labels with use of ids and aria-labelledby improves it for non-sighted users. aria-labelledby can include multiple associated ids, each of which a screen reader will read out on focussing the input element.

`<textarea>`

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea#

<textarea> elements are much like default text input fields except that they support multiple-line input. Default functionality also allows for the user to expand or shrink the box as they desire. Labels and aria-labelledby should also be specified here.

There are, of course, other interactive elements which you can consider using such as the <details> element which acts as a basic accordion component; or the <area> element which is used to specify areas within a single image which take the user to different locations on activation.

Bespoke Components

But what we want isn’t always available “out the box”. Especially with the rise of JavaScript on the web and more creative design, many people are moving in favour of bespoke component creation and implementations. This is particularly true with the use of frame-working languages such as React. There isn’t anything inherently wrong with such a venture, in fact, I encourage you to test your creativity and to learn, however, bear in mind that what is already included within your base HTML is more than meets the eye. For example, creating your own button component is fine, however I encourage you to add in the key-activation functionality for keyboard users which is found on a vanilla <button>.

Remember that computers can only do what you tell them to do. If you are building a component from scratch, then it is also you who should be building ramps and guiderails.

Testing

It can be a bit much, knowing when to use an attribute or where an element should be replaced with another, but gladly there are many testing websites, plugins and resources that exist to help you. Below, are some brief introductions to some resources regarding testing. Unfortunately, while there is extensive documentation regarding what is required to make your site truly accessible to all, automated testing of such considerations is difficult to achieve. I hence suggest the use of multiple automated testing platforms to wheedle down the issues. Additionally, I suggest the use of both automated testing and manual testing when assessing your site for accessibility concerns.

Lighthouse Accessibility Audit

https://web.dev/measure/

Created by Google, the lighthouse accessibility audit tool can be accessed either through the development tools of Chrome-based browsers (Inspect > Lighthouse) or by visiting the web.dev website. An automated audit tool, Lighthouse targets the most obvious of accessibility issues while also providing you with a list of manual checks you should do in addition.

Tota11y

https://khan.github.io/tota11y/

Created by Khan Academy to decrease the entry-barrier when testing for accessibility. Providing annotations, simple descriptions and sometimes solutions, tota11y is available as a bookmarklet application on all desktop browsers. It is easy to setup and deploy (literally drag and drop) and is a great tool for catching mistakes while you are developing.

Axe Accessibility Checker

https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd

Created by Deque, an accessibility advisory body, axe DevTools is a Chrome browser extension which adds itself to the list of tools within the browsers’ developer toolbar. This tool can allow you to test specific parts of the page which you can select individually, creating an easier experience for the user.

Microsoft Accessibility Insights

https://accessibilityinsights.io/en/

Like the Axe Accessibility Checker, the Microsoft Accessibility Insights tool is a graphical extension for both Chrome and Edge. It includes two sets of testing, one called the FastPass set which is quicker, covering the most common accessibility errors. The second is called the Assessment set which is more in-depth. Both sets also include instructions for how to manually test your site where an automated test cannot (such as checking tab-order). I recommend FastPass for during development to help catch errors you may be making and Assessment for when you are nearing deployment.

Manual Testing

The behaviour of a human user will always be difficult to predict, and hence manual testing is an incredibly valuable part of accessibility testing. In the interest of building a baseline of understanding within this document, I will now outline some of the simple checks you can do to check the accessibility of your site. Remember that not all people can use a mouse nor see a screen so even missing one of these points can significantly affect their experience on your site.

“I can easily navigate the entire site using the keyboard only”

Try navigating your website using only the keyboard. Use [tab] and [shift] + [tab] to move up and down the DOM, [space] or [enter] to try activate content. Within the Developer Tools Console you can add in a custom rule for document.activeElement to ensure you are focussing the element you think you are (Dev Tools > Console > eye icon). This can be especially useful when you have elements wrapped within one-another and you’re uncertain on the default focus behaviour of each element.

Every interactive element is focusable

“I can use [tab] to focus every interactive element on the page”

If an element is not focusable through keyboard control then it is unable to be activated by some users. This ties closely to the use of correct semantic HTML elements. If you include a <div> element with an onclick attribute, it will house that functionality but be unable to be activated through keyboard input only. It is best practice to use a <button> in this case.

Every focusable element is visible

“I can see where I am focusing at every stopping point within the page”

Sometimes, we wish to hide elements visually before they are activated, such as a navigation menu. Note however that [tab] moves the user down through the DOM and hence cares not for where and how a component is rendered on the screen. There is therefore a strong chance that a sighted, keyboard-only user may lose their place on the website if they [tab] to hidden content. This can be incredibly frustrating when there are, for instance, many navigational items within the hidden menu.

To fix this issue, you should make use of display: none in your CSS. Setting the property to display=”none” will remove it from the interactable DOM, thus hiding it from all users. Adding in a toggle for this property within the associated onclick function allows you to control this behaviour, adding and removing the content from the page as needed. Note that the visibility property also exists, which removes the content visually from the page, however, it doesn’t remove it from the flow and hence is not an alternative to display: none.

Every interactive element has a focus outline

“I can visually see where I am focussing on the page”

https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

https://developer.mozilla.org/en-US/docs/Web/CSS/:focus

By default, browsers will include default focus styling on all interactable elements. For Chrome, this looks like a blue ring around the focused element. Never remove the default styling without replacing it with an alternative which meets the WCAG specifications. You can also look at including :focus-visible and :focus-within pseudo-elements to your CSS styling for even greater visual communication of your site.

Focus Order (Tab Order)

“Navigating my website by keyboard makes logical sense”

Most websites which you will encounter early in your career will likely exclusively use a left-right, top-down based script and so the tab ordering is something which we can check by simply seeing if the progression feels natural, matching the visual order. Check if your [tab] ordering completes each block of content before moving onto the next and whether it follows the natural progression of reading a page.

Dialog (Modals)

https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal

Dialog modals are activatable pop-up boxes designed to provide additional information within an individual element without taking the user away from the original webpage. Designers love them, and they can be used to great effect, but there are several accessibility concerns which arise with modal use. The most significant of these concerns relates to focus ordering, where you must first ensure that the modal content is passed the focus on activation. You should also ensure that the base page is no longer focusable and hence that the modal’s focusable content will loop. Lastly, you should ensure that on closing the modal (which should itself be possible through use of the keyboard—[esc] is a common key for this) that the focus order has been maintained, returning you to the point where you activated the modal. If for some reason the modal portal no longer exists, focus should be placed in the position which makes most logical sense next in the structure.

Infinite Scrolling

https://www.deque.com/blog/infinite-scrolling-rolefeed-accessibility-issues/

Infinite scrolling is a nightmare. With its inception, infinite scrolling found its home within social media sites before bleeding into eCommerce and news platforms. It was designed to reduce the number of clicks a user needs to find the content they are looking for but has come with significant drawbacks — and it’s not only users with disabilities who are impacted. General performance decreases, footers becoming obsolete (if they’re accessible at all) and hits to your performance metrics can all be expected with this feature. Avoid using infinite scrolling, if possible, for you may find yourself in an accessibility hole if you do.

Checklists

Visual:

Text is of a suitable size (minimum 12px)
Text can be scaled up by the user agent without the loss of content/functionality
Text has sufficient colour contrast compared to background
Colour is never used as the sole indicator of a change
Content blocks are distinct on the page and the layout makes sense
Focusable content has a distinct focus-outline
Auto-played content can be paused or stopped
Used media-query to check for prefers-reduced-motion
Flashing/blinking content falls within requirements
User inputs are statically labelled
Interactivity bounds are large enough, including on mobile
The page can be zoomed to create a single column of content with no extra scrolling

Contextual:

The page’s structure is easy to follow and matches the DOM
Navigation links are within a <ul> element within a <nav> element
Current page is indicated in the <a> navigation component using aria-current
Repeated content at the start of the page is in a <header> element
Main page content sits in a <main> element
Repeated content at the end of the page is in a <footer> element
A skip link is provided to skip repeated content at the start of page
All images have alt-text (alt) attributes
SVGs intended as images have aria-label in place of alt-text, have role=”image”
Decorative images are given an empty alt attribute, alt=””
Links and buttons have accessible, and descriptive, text
Link descriptions make sense out of context, use aria-label and aria-labelledby
Correct semantic HTML elements are used for all interactive elements
Headings are in descending order and don’t skip levels
Bespoke JS components consider accessibility and aria attributes

Testing:

There are no major issues raised from your chosen automated testing platform(s)
Everything on the page is easily accessible by keyboard only
By using [tab], all interactive elements are accessible
All interactive elements are clear on the page while targeting, with focus styling
The focus order follows a normal visual order
All modals consider accessibility concerns
Any infinitely scrolling content can be skipped over and/or escaped from