Written by
Adina Milica
, Graphic & UI/UX Designer
Digital content accessibility is all about ensuring that everyone, regardless of their abilities, can easily access and engage with the content you share online.
This concept goes beyond just providing information; it's about making sure that your digital presence is inclusive and welcoming to all users.
How does this translate into more specific things?
- Let’s clear up some common myths
- Web accessibility principles
- Why does digital accessibility matter
- Web accessibility standards
- How to make your digital content accessible
- About audits | What do you need for a web accessibility audit? 🤔
- The digital content accessibility checklist ✅
- Closing thoughts
Let’s clear up some common myths
Myths about accessibility get in the way of real, thoughtful progress, so no more of that. 🙅♀️
First things first, your content is not only viewed by perfectly abled people and, also, its accessibility is not requested only by people with high levels of disability.
Secondly, disability isn't always permanent. For example, a mother carrying her baby is situationally limited in her abilities, just as someone with cataracts experiences temporary impairment. While they may not be disabled for most of their lives, there's still a significant chance they will encounter challenges when interacting with your content
Once you understand these 2 nuances of web accessibility, everything else becomes much easier.
Web accessibility principles
Ideally, your digital content is defined by the following web accessibility principles as defined by the Web Content Accessibility Guidelines (WCAG). If you want, you can remember them easily by the POUR acronym:
- Perceivable - users can perceive your content by means of the senses (vision, touch, hearing).
- Operable - user can successfully use controls, buttons, navigation, and other interactive elements.
- Understandable - user comprehends your content with ease because of its consistent format, predictable UX, familiar voice & tone.
- Robust - user can interact with your content by any technology that helps them in interacting with digital content (from keyboard to screen readers).
Now we know what digital content accessibility means in general terms.
You may have already understood these things, but maybe you're still wondering if digital content accessibility is something you should focus your time on. ⏳
Why does digital accessibility matter
Pure morality
Simply put, access to digital knowledge shouldn't be reserved to people with perfect vision, perfect motor skills, perfect lives that never limit their interaction with a screen. It's a no-brainer. Having decent accessibility on your online content is, first and foremost, the moral thing to do.
Market value
Despite your personal commitment to corporate morality, when motivating allocation of time resources on a new area of work it's important to know what economical value that area will provide for business.
There's this myth that improving accessibility on your website is just related to "doing the good thing". There is a giant market that you might miss if your website and its content is hard to access for people that value accesible websites - possible clients equating to a 13 trillion dollar market. 💸
Employee consideration
If we're talking digital content directed to your internal team or to possible talent that you want to attract in your company, note that employees with disabilities make a possible 25% of the corporate workforce. Not all your colleagues or employees will talk about their disability and the issues that surface through that said disability. This is due to many factors, but, as an employer, the factors are not in your control most of the time (you can try surveys, workshops and stuff like that, but past workforce trauma may get in the way of open communication even in the best kind of teams).
Repeat after me: It is the duty of an inclusive workspace to inherently support any level of ableness whether or not that said level is perceivable.
That is clearly in your control.
Compliance
When accessibilty is not a thing of empathy or strategy as discussed above, it is a thing of respecting the law and, well... not getting fined.
There is less than a year until the European Accessibility Act (EAA) becomes law in all EU member states. Until 28 June 2025, each member state will have published their own individual laws, detailed regulations and respective fines.
Who does it apply to?
- It applies to any business with at least 10 staff and a turnover above €2 million.
- It applies to any business that trades in the EU.
- Companies headquartered based outside the EU must comply with the Act if they sell relevant goods or services within the EU.
Even if your country hasn't yet published their EAA, the checklist that we discuss in this artcile will cover most of your pain points, enabling you to have a big head start.
Web accessibility standards
Setting up for your journey into web accessibility will mean choosing a clear source of truth.
The most extensive and popular standard is Web Content Accessibility Guidelines (WCAG) with its corresponding levels of conformance - A (lowest), AA (mid range), and AAA (highest). You should aim at least for WCAG 2.1 Level AA which is the recommended level of compliance, addressing common barriers for disabled users.
Other standards that you may want to consider for additional research are:
- BITV (Barrierefreie Informationstechnik-Verordnung) - especially important if you have a german platform
- ADA (The Americans with Disabilities Act) standards
- a11y guidelines - a11y is a community-driven effort to make digital accessibility easier.
- ATAG (Authoring Tool Accessibility Guidelines)
- if you're conducting business in EU, your country's EAA might be the best source to follow, from a legal standpoint.
How to make your digital content accessible
Now, there are 3 big roads on which you might find yourself...
In case #1: You got to start with an audit, there's no way around it. You can't just start tinkering with stuff, it will turn into a project management nightmare.
In case #2: Skip to this list and read the TL;DRs so you get a high level vision on which points projects should touch on at least a bit when talking about their own accessibility.
Also, as subjective as it may seem, I'd advocate for looking into open-source projects. If there's anything missing in regards of accessibility, you can always easily add what you need and contribute at the same time to ethical software. If by chance you're looking into accessible knowledge management software (knowledge bases, intranets, documentation, all the good stuff), just check XWiki's own journey, standards and progress on accessibility.
In case #3: Good code will do all the trick for you. Skip to this list and understand what you need to further investigate if you don't already know it. Also, by the way, you don't have to build everything by yourself. There are lots of open-source libraries that can support your project and you can also contribute to them, so it's a win-win.
About audits | What do you need for a web accessibility audit? 🤔
It all depends on your time resources.
Ideally you'd go through more than sample pages. You'd check if all icons and images have good alt text, if the content can be optimized to have more straightforward ideas and include everywhere needed some Skip to content buttons.
While this is something you should aim for, let's start with the basics first: establishing the sample pages to analyze in your audit. These are:
- the most used pages (blog pages, homepage, pricing pages, contact page, documentation etc.),
- templates (meeting notes, new task, new project) & dynamic pages (user profiles, forum posts, etc.)
- components (forms, carousels, galleries, buttons, inputs, etc.)
- log in / sign up / log off screens
- add new page screen, edit page screen
- a sandbox page, if you have one, where you have any possible UI component and element that you can think of from your platform/website (this will come in handy for many types of audits, not only for an accessibility one)
- any other page that your team and/or your users use a lot
After deciding on your sample pages, talk with your team about what time resources you have available. Be realistic and understand that while you may want to push full-force for a better digital accessibility in your content, others may not feel as strongly. Unfortunately, accessibility work always gets delayed in corporate teams as its ROI is not easily identifiable.
If you have a lot of time resources ready to be allocated and also have some team members available to assist with the audit, you could consider doing this in-house. If you'd rather let your people focus on something else, you can delegate the task of the audit to an expert team. For any of these methods, see the next section for some considerations.
Can you do a web accessibility audit in-house? 🧐
If you don't have a complex website/platform to analyze, you can definitely do an accessibility audit with a part of your team. Just go through a checklist like the one in this section, use an online web accesibily evaluation tool and you'll be done pretty soon.
But... what if your platform is very complex, with lots of custom functionalities, legacy code, lots of important sample pages? 😬
Then a list like the one in this article will give you a great starting point and an overview, but you'll need more. Truth be told: the best checklist that exists for digital accessibility cannot be effectively produced by an article. It already exists as a whole project and it's called, you guessed it, WCAG.
For highly complex projects, you need a team of accessibility experts to review your platform. They will take every WCAG criterion and make sure every element in your selected sample of pages respects the criteria. If it's not a full YES, then they will explain how it does or doesn't meet the criteria. Ideally, they will propose acceptable and ideal implementations considering your possible time resources.
Accessibility evaluation tools that work great
Our experience
This is what worked for identifying accessibility issues in our complex product, so I thought I'd share.
XWiki moved at some point to using Axe Core to detect violations against WCAG 2.1 (AA level). Axe Core is a fast, secure & lightweight accessibility testing engine chosen by our devs thanks to its easy integration in our current testing environment. Developers also use WCAG validation tools like Axe devTools directly in their browsers to reproduce issues on their computers with ease. This approach makes it quick to visualize and resolve issues.
A list of other possible tools for checking and validating accessibility issues was made available by our accessibility expert, Lucas Charpantier:
| Online | Browser-based | Manual testing checklist |
|
|
Testing on multiple screen readers
If you want to do accessibility right, you should definitely test your content on multiple screen readers in operating systems that your people work on. Unfortunately and fortunately at the same time, not all screen readers work the same.
When testing manually for screen readers be concious of myths like:
- Myth 1: Everyone with blindness or low vision uses a screen reader to "listen" to content.
- Debunk myth 1: Some people use screen magnifiers, refreshable Braille displays, high-contrast modes, or some combination of tools.
- Myth 2: Only people with blindness or low vision use screen readers.
- Debunk myth 2: More than 12% of a survey's respondents said they don't use screen readers because of a disability at all. Screen readers can be helpful for people with lower literacy, for non-native speakers, and for anybody who prefers audio content in comparison to reading.
Now, here is a list of screen readers you migth want to test on:
List of free and open source screen readers | List of most popular screen readers |
|
The digital content accessibility checklist ✅
#1 Semantic HTML is your friend
We all know what HTML is, but what about writing semantic HTML? Long story short, it means picking the right HTML element for a certain job in the context of your web page. Doing this gives your page structure, context and, more importantly, meaning.
Let's just take an example.
Coding is governed by freedom. That means developers have the freedom to choose a div over any other type of element and just slap a CSS class & some JavaScript on it. The coder's CSS & JavaScript efforts might make the div seem like, for example, a button but, at the end of the day, it will never be fully like a button.
Assistive technology and, more specifically, screen-readers rely on semantic HTML to convey each screen element to the user.
Job-specific elements like buttons, checkboxes, radio buttons, forms & others come by default, in any browser, with a pretty useful stack of behaviours. These features are essential for users who rely on assistive technology, as they help them interact with your content and access the information they need in a way that works best for them.
#2 Keyboard usage is more important than you may think
We can't talk about digital accessibility and not talk in depth about keyboard usage.
From motor disabilities to vision impairments, many people rely on good keyboard support in their every day lives. Heck, there are a lot of people that don't have any disability and still prefer to user the keyboard to navigate the internet. Let's see how you can support them.
Focus indicators - don't hide them
A keyboard user navigates through a page's interactive elements (links, buttons, fields) with the help of the Tab key. Obviously, the user shouldn't need to go full on detective mode to identify which element has he Tab-ed to. The user must receive a clear visual indicator for this. This indicator is called a focus indicator and it's provided by browsers for every interactive element by typically outlining the focused element.
Technical solution: tip #1 and #2
What comes next? A quick look into navigation order
For users that rely on keyboards, the order in which they are presented things is essential. It has to make sense and come naturally. The order is based on your page's structure and, thus, code. Esentially, if you HTML code is well made - make use of the right elements and regions - you're probably in a prettty good point.
Interactivity - All HTML elements are equal, but some are more equal than others
It may seem normal to want any element of your webpage to be keyboard focusable. The thing is... that's not good.
Only elements that can be interacted with the mouse or touch should become keyboard focusable (links, buttons, inputs).
Technical considerations: See tip #4, #5, #6.
Explaining tip #7: keeping non-interactive content separated from the interactive one will help people that rely on assistive technology immensly. They won't have to tab 30 times through 10 photos, 10 paragraphs, several rows of tables and a GIF that they can't watch just to get to a button that gets them to the next article. For users with motor disablities, this is, many times, an exhausting effort.
Custom widgets VS the keyboard: a battle worth having
When you read the semantic HTML part of this article, you may have thought: Well, if there was an HTML element for my usecase, I would've used it.
Of course, custom elements are inevitable especially when we want to create unique user experiences. But just because they are unique, that doesn't mean they shouldn't be accessible to anyone by keyboard. Alternative keyboard controls must be provided for any custom element, in a intuitive & predictable way, with standardized keystrokes. In this process you might need to use Accessible Rich Internet Applications (ARIA).
Keyboard traps
One thing to look out for in your accessibility audit is what is called a keyboard trap. This occurs when a keyboard user cannot move focus away from an interactive element. Carroussels, modals and cookies are infamous for their talent on creating keyboard traps.
Carrousels, besides their UX impracticality (only 1% of users clicked on carrousels call-to-actions), are usually a nightmare for keyboard navigation because of their difficult configuration of tab focuses. On modals and cookies, the issues are more varying. They often suffer from poor form labeling and bad use of semantics related to dialog elements. See this great article from Marcus Herrmann for some details on cookies' accessibility.
#3 Contrast really shouldn't be a problem we still have in software in 2024
You knew we were going to get to this: color contast and, in general, colors usage is one of the main aspects of web accessibility.
No, accessibility shouldn't limit beauty, but beauty shouldn't limit accessibility.
If you're building from ground up: don't hard-code your colors.
- Choose a nice accessible range of colors with lighter and darker shades derived from your brand's main colors. These are two websites that I use to generate / verify my colors and they work pretty nice (non-sponsored): Color Contrast Checker , Youtuber Juxtaposed's Real Time Colors, Color Designer.
- Create CSS/LESS variables for them and only use those.
Alright, now let's talk about WCAG.
WCAG defines contrast as: a measure of the difference in perceived "luminance" or brightness between two colors. There are many calculators online, so you only need to worry about the contrast value (don't round them up):
| Type of content | Minimum ratio (WCAG AA rating) | Enhanced ratio (WCAG AAA rating) |
|---|---|---|
| Body text | 4.5 : 1 | 7 : 1 |
| Large-scale text (120 - 150% larger than body text) | 3 : 1 | 4.5 : 1 |
| Active UI components, icons, graphs/charts | 3 : 1 | Not defined |
| Pure decoration elemnts, invisible elements, logos, brand name text | No contrast requirement | No contrast requirement |
| Text over gradients, semi-transparent-colors, background images | Not defined by numbers: While WCAG doesn't provide a way to measure the contrast in this cases, the text should still be easily perceived and, thus, meet contrast requirements. A suggestion is to measure the contrast in the areas you feel like there's the least contrast an start from there. | |
| Text in different states of a UI element | Not defined by numbers: Let's take, for example, a button. In some states it wil get darker, in some lighter. You should test for contrast every state independently. | |
#4 Sizing - you shouldn't need a magnifying glass on the web 🔎
Default size of interactive elements
To summarize what WCAG already said very nicely:
Zooming
#5 Form labeling done right
You'll for sure make use of forms in your sample pages. All forms are made of form controls - the elements through which the user inputs text or selects options or submits data.
Example for tip #2:
<label for="name">Name:</label>
<input id="name" type="text" autocomplete="name">
Explaining tip #3:
As explained in detail in Tehnique H65 of WCAG, it's a good idea to use the title attribute to identify form controls when the label element cannot be used or its usage would create more confusion.
Explaining tip #5:
Having autocomplete capabilites makes a huge difference for anyone that is in a hurry, but also, more importantly, for people with motor disabilities resulting from nerve damage or for people with cognitive disabilities. People that went through these experiences accentuate how much effort a single search takes and how slow the process is in some instances.
As WebAim explains: "Users can benefit when common field types (name, address, birthdate, etc.) are represented consistently across the web. The ability to programmatically determine the purpose of each field makes filling out forms easier, especially for people with cognitive disabilities."
#6 Alternative names & text - it's easy, just give more context
Screen readers announce alternative text in place of images, helping users with visual or certain cognitive disabilities perceive the content and function of the images.
Good alt text = how you’d briefly describe the image over the phone. Concise, but specific. Length: a few words or, at maximum, a full sentence. Keep alt text under 125 characters so screen readers won't cut it off.
| Never start with “Image of …” or “Picture of …”. It can get annoying to hear your screen reader repeating "Image of..." 20 times while trying to understand a topic that is explained a lot through visual material. If it's relevant, just specify the angle or type of the picture (headshot, portrait, polaroid, cartoon,etc.) or just stick to describing the picture. | Alt text isn’t needed if it repeats what’s already on the page. Example: If you follow an image with an actual explanation of the image, you might be better off with a very succint alt text or none at all. No one wants to hear the same thing twice. |
Include text that's part of the image. If the text is relevant to the whole page content, it is advisable to include it in the alt text. | Don't add alt text to 'decorative' images. This way, screen readers will skip the interpretation of that image making the experience smoother and skipping non-important content. | Using correct grammar can enhance the experience for screen reader users.
|
Closing thoughts
Thanks a lot for reading so far! The mission of digital content accessibility is an important one affecting lots of people worldwide. Through understanding the main issues about it and making sure you're implementing the rights solutions in the right way, you're paving the way for a better digital future.
One more thing and then I'll leave you to it:
In case you're interested in stuff around knowledge management, ethical business, human support, accessibility and remote work, maybe you could join our community by subscribing to our monthly newsletter. 🤗
Okay, have a great day and see you next time!
