-
https://smth.uk/rem-based-media-queries-are-weird/ "1rem in a media query condition, is not necessarily equal to 1rem elsewhere in your CSS. While 1rem everywhere else is equal to the font size at the html element, in media queries it is always equal to the font size set in the browser preferences."
-
WHC semantic elements are treated differently to aria-based ones
-
landmarks
-
headings - reference table of contents in MS Word
- how design systems should divorce heading semantics from visual size
Communication
For a user, any user, to successfully use our site we need to be able to communicate with them:
- consuming and understanding the content, whether that is plain text, a table of data, an image, a video or something else
- reducing cognitive load so the user can focus on what is important
- making the user aware of any updates, notifications or changes to the page content
Semantics and implicit roles
You will often hear people talking about semantics when discussing HTML, perhaps along with “use the right element for the right reason”. For example, if you are wanting to show a heading, then use the correct heading element (such as a h3) rather than just making the text bigger.
The reason for this is that every HTML element has what is called a “role”. This is the meaning of that element and this is a very important part of making a page accessible. This role carries a lot of information to screen-reader users, information which another user might derive from the visual representation of that element on the screen.
By using semantic HTML we can get a massive jump-start on supporting users who use assistive technology, for free.
Many (but not all) HTML elements have implicit roles, for example:
h1toh6haverole="heading"ahasrole="link"fieldsethasrole="group"ulandlihaverole="list"lihasrole="listitem"divandspanhaverole="generic"
We can also create or manipulate these roles ourselves using something called Aria as well as add others to make more complex interaction elements.
You can already tell just from these role names how this can help non-visual users understand our page and how important it then becomes to be careful in how we use these elements.
Depending on the role used, the screen-reader user might also get other information. For example when they encounter a list role such as a ul, they may also be informed how many child listitems (or li elements) it contains. This all helps communicate information to the user, helping them build a sense of the page.
For this reason it is important not only to use the right element for the right situation, but also to only use those elements for their given function.
Consider the entire journey
There is little point in having an accessible site if your entry and exit points are inaccessible. Check things like the login journey and social media presence for the inbound. Check support mechanisms such as webchat, phone, email and any online help documentation for outbound. If your product relies on 3rd party services, such as a job site to display vacancies, is this accessible?
Then look at the product itself. Are the tasks for the user considering the user, such as cognitive conditions. For example, does it rely on short or long term memory; could a user exit a task part-way through and come back later without losing data if they become fatigued?
Understanding the content
This is the basic building block of the site, if a user cannot understand what we are trying to communicate then the site is going to fail in its purpose, whether that is submitting a tax return or selling clothing. So for each user we need to consider if they can actually perform these functions.
For example, is the content written in a way all our users will be able to understand? Has it been broken up into logical sections to make it easier to digest? Do images have a text alternative so those who cannot see the screen can still undestand what we are trying to communicate with them? Does the message we are presenting with our markup match that we are presenting with our visual design?
Is there content which can only be seen by some users? For example does the user need to use a mouse to hover over a control to show additional information? How would a keyboard user or someone using speech-recognition action that, or even know it is there?
We need to examine all our content and how it is marked up to ensure it is well coded to support the different types of user.
Communicating updates
When we change something on the screen, such as triggering a notification or showing an error message, we need to especially consider all of our user groups. Those who cannot see the screen need to have that notification communicated in another way - how do we tell them something happened? The same goes for those using screen-manification tools - if the notification is off-screen, how are they to know there is something they need to pay attention to?
Visually this is simpler when the updated part of the page is located adjacent to the thing (for example a button) which triggered the update. Closely located trigger and response means screen-magnification users, and those using mobile browsers, will be more likely to notice the change.
Screen-reader users will normally need to be notified of changes using aria. This can alert them to content change either by announcing that adjacent content has appeared, such as updating an aria-expanded attribute. Or it can be more complex by using aria-live regions, but be careful not to just have this read out the entire content if the update consists of more than a brief sentence.
When updating content, thought also needs to be given to keyboard-only users. The new content might need to be added to the native tab order so the users can easily navigate to it. If the update means the element the user was focussed on is replaced or removed, then that focus needs to be handled by placing it thoughtfully elsewhere. Failing to do this can mean the user is dropped back at the top of the page which can be disporientating and frustrating.
Modality
When thinking of accessibility we should also consider how different users might consume the page.
Page zoom
One example is page zoom. Even if we don't expect the site to be accessed on a mobile device, we need to ensure that it can cope being displayed in that format.
This is because some low vision users will user browser page zoom to increase zoom to 400% or more. On a 1280px wide screen this will equate to a 320px wide display - the same as a small phone. If we don't ensure the page reflows to the new viewport size we risk excluding users, or at least making it very difficult for them to use it.
By designing from a mobile-first standpoint we can help users who may use browser zoom on their desktop. This also shows where potential friction points can appear early on and allow them to be designed out at an early stage.
When it comes to mobiles and tablets we should also test our work in both landscape and portrait modes. It is easy to forgot a site may be used in either orientation and end up with an unusable site when a sticky navigation takes up the entire screen in landscape.
Font sizing
Whilst page zoom can be enough to satisfy WCAG criteria for font-sizing, some users may find it better to just increase their font size. This can be especially common on mobiles. By using responsive font units for text and also ensuring containers (and media-queries) are sized in font-relative values we can ensure the design flexes with font size too.
Functionality
Now for interaction. This is often where sites can fall down on accessibility. Can the user perform all the actions available? This might seem a simple thing, but it is all too easy to check some functionality works with a mouse and forget to check if those who cannot use a mouse can perform the same action - or how about those who use speech-recognition to trigger that action?
Performance
Performance is often not considered part of accessibility but it can have a direct relationship. People with diabilities may be using older technology. This may be due to financial reasons as these users often have lower disposable income, or due to reluctance to upgrade the technology which they rely on in case something goes wrong.
Sites reliant on heavy client-side processing, especially ones which do not use semantic elements (and so requiring even more processing) can lead to assistive technology struggling to keep up. We can help by reducing the amount of javascript to provide more resources to assistive technology. We can also reduce the size of the accessibility tree - for example by avoiding adding regions or aria attributes where they are not needed, and using semantic HTML. Reducing the amount of nesting of elements (DOM depth) and number of nodes can also help with performance and allow assistive technology to work more effectively.
Watch Eric Bailey on the intersection of accessibility and performance on YouTube
Content formats
Much of what we produce in the digital space is rendered as HTML, but the principles apply to all document formats. Done well, HTML is generally the most accessible format as it allows a great deal of manipulation by the user - for example increasing font-size, reading with a braille or screen-reader, changing colours or fonts, reading on different sized devices.
However there are other formats which may be required for one reason or another. The same principles apply whether that is Word, PDF
Too much information can be as bad as too little
It can be tempting to think that adding custom accessible names to all of our elements will help screen-reader users, but too much information can be as much of a barrier as too little. Overly descriptive interfaces can make it very difficult to understand the page.
In fact we should be very selective in where we add additional content which is not visible to all users. We should question why a screen-reader user needs that content when no-one else will get it, remembering we might be making it more difficult for speech-recognition users. There should be only a few isolated places where we do so.