- styling - using accessible selectors like .thing[aria-expanded="true"]
- links - need to have an href to be keyboard and screen-reader accessible
- skip links
- landmarks
- not contraining container height - allow text to grow
Looking at a site in layers
If we take a look at a site with all the visual design, styling and interactivity stripped away we are left with content. At this point the site is effectively a tube of content which can be read, viewed on different devices and zoomed in with the browser's built in tools.
Then we will look at building our layers back in and examine a few of the issues which we might encounter along the way.
Page language
The language of the page needs to be communicated. This not only helps with automated translation services, but for screen-reader users it is essential for them to get the correct pronunciation by selecting the right speech engine.
This is done using the lang attribute:
<html lang="fr">
[Example of French page with and without correct language setting.]
Within a page we can also indicate snippets of languages which differ to the wider page by using the language attribute on a containing element.
Page title
The page title is what is displayed in the browser tab, so it should tell the user what the page is and what the site is.
Whilst you may not be able to see all of this informaiton without hovering over the tab, it is shown for keyboard users when they are focussed on the tab (or the close tab button) and is also the first thing announced to screen-reader users when a page loads. This means it is important that it is not left to be the same on each page.
Content
The “tube of content” is our starting point, but it also needs to have some attention to make sure it is accessible. Content is key to a user understanding the page so it is important that it is written so as many people as possible can understand it.
All of our content also needs to be marked up correctly using semantic HTML - this is very important for assistive technology as we have seen.
We will need to revisit our content as we add more elements to the page to maintain accessibility.
Links and other controls
Now let's turn our attention to our links, buttons and form inputs. We need to make sure each of these is reachable and operable with just a keyboard. We also need to review the accessible name for each to check it makes sense and can be guessed from looking at the visual design (so ideally has text which matches the accessible name).
Images and media
Images
When we look at adding images, they are split into two main types - decorative and non-decorative. Decorative images are ones which could be removed from the page and it would not affect the content. Perhaps this is an icon which has visible text alongside it - in this case we can remove the icon without affecting the understanding - this is an example of a decorative image.
If an image has meaning, for example it is illustrating something, then it should have an accessible name set using the alt attribute. This means a non-visual user with a screen-reader will still be able to follow along an understand the image. Alt text copy writing can be something of a skill in itself as we need to balance description with being succinct.
Something to be aware of is that image alt text is very dependent upon the context (the reason it is there and the surroundig copy), so the same image used in two different pages might have different text.
Charts
Can charts and diagrams be easily understood by users with cognitive impairments or those who cannot see the screen? Do any uses of colour provide enough contrast? For charts in particular are we hiding additional information behind hover tooltips which can't be found or actioned without a mouse or pointer?
Animation and video
When it comes to animation (including video) we need to be mindful of how movement can be a trigger for some cognitive conditions, especially things like parallax scrolling or auto-playing videos. If using such things are used we should be providing mechanisms for the user to stop them, either via direct controls or using preference media queries. For media, have we considered alternate ways of consuming it - such as adding a transcript and captions or audio description to a video?
Avoid autoplaying video for the above reasons and because having to stop something means additional effort, which for some users may mean they then don't have enough reserves to finish the task they came to your site to do.
Autoplaying video which has audio will also interfere both with screen-readers (as their output is audio) as well as speech-recognition (as audio is how the user controls them).
Layout
Now we have all of our content in place, let's take a brief look at layout and how that can affect accessibility.
Still looking at our simple tube of content, typically we want to start off with the most important content at the top of the page, after the main navigation. This means for mobile viewports this content then comes first in the source code and we don't need to use css to switch layouts around which can cause issues for keyboard and screen-reader users.
As we add in our layout styling we should look out for components which create horizontal scrollbars and indicate the component is not fully responsive. Two dimensional scrolling (both horizontal and vertical scrollbars) can cause issues for screen-magnification users as it will make it much more difficult for them to read the content. Having to manipulate additional scrollbars can also be difficult for less technically proficient users or those with motor skill impairments.
As we move from a mobile to wider viewports we need to think about screen-magnification users. As these users might only see the screen a small portion at a time we need to be alert to any places where related content becomes separated by areas of horizontal whitespace. This might make it difficult for these users to either be aware additional content is present or that two items are in fact related.
Interaction
When we look at bringing in dynamic elements and interactivity to the page, this is often the place where barriers are created.
As we have already said, communication is the keystone to accessibility. When we make in-page updates, whether that is content changes, popups, notifications or menus, we need to consider how that will be accessed by keyboard and screen-reader users.
For example, when we open a side-loading menu from a hamburger button we need to manage the keyboard focus by placing it on the menu. If we left it on the button it would make it difficult for a keyboard user to know how to access the menu (especially as these kinds of menus are not normally in the same place in the DOM as the button which activate them).
Some interactions may require us to add hints to screen-reader users that something has happened. In the menu example above we would want to indicate whether the menu was open or closed by updating the button with some sort of status. This way when we return the user to the button when they close the menu they get confirmation that the menu has been closed.
<button aria-expanded="false" aria-pressed="false">Menu</button>
<!-- “Menu, button, not pressed, collapsed” -->
<!-- Menu is closed -->
<button aria-expanded="true" aria-pressed="true">Menu</button>
<!-- “Menu, button, pressed, expanded” -->
<!-- Menu is open -->
The wider journey
We also need to look beyond our individual pages and think how a series of pages interact as part of a journey. This becomes especially important in situations where some sort of multi-step transaction is taking place, such as buying something or submitting an application.
When a user has a disability or condition it can take them longer to read, process and interact with a page, so any kind of time limitation can be a barrier.
giving enough time memory