What exactly is included in it then, and what does it mean to the people who create such websites and applications?
This is exactly what you will be reading about today 🌱
Why was this article created?
As Brave New, we have had several opportunities to create websites for public institutions – a great example here would be the National Archives in Krakow website – and each time, we have met the challenge of replicating what is included in this act.
Challenge difficult to the extent that the requirements for accessibility are not something you can implement once in an ordered and neat way, but something more like legislation – a thing that has to be as universal as possible and functional for everyone, taking into account their differences. In the case of accessibility – the cognitive differences.
That is why in our company’s knowledge, there was a gap to fill in.
I have filled it in before within our internal knowledge, and now I decided to publish it in the form of this article so that you also could use it.
A few potential questions and answers:
Why have some of the points been left out?
The numbers are taken from the WCAG specification, and the act itself just doesn’t have it – I want the article to strictly cover the act. For all the guidelines WCAG 2.1 (or the latest, not yet widespread version 2.2) in detail and more descriptive form with examples, scroll down to the end of this article ✨
What do I provide in these points?
Each description will explain to you, in summary, what should be implemented for the specific criteria to be met. Apart from that, all of the points have been linked to the WCAG documentation where you will find all of the information as well as examples and recommendations. They will be particularly helpful if you implement these things for the first time.
I am not even trying to describe each of the techniques as well and thoroughly as it is done in the documentation. If I wanted to do that, I would have to copy it and this article would be 10 times longer than it is now.
That is why you will learn the most from the documentation itself, which I have linked in the sources at the end of this article.
So, what does the websites and mobile applications accessibility act consist of?
Below, I am presenting all of the requirements, reworded by me so that they can convey the meaning of certain criteria as clearly as possible.
Requirement 1: Visibility
1.1 Textual alternative
All non-textual content (images, videos, multimedia and interactive elements, etc.) should have a textual alternative that describes its:
- way of working;
- or performs the exact same function (in the case of buttons).
1.2: Accessibility of time-varying media
In short – media based on senses cannot rely on only one of them.
Audio or video elements should have their textual alternatives or audio descriptions showing the exact same content as the original multimedium.
All recordings consisting of both audio and video should have subtitles containing descriptions of all the significant sounds from the extract (noises, dialogues, etc.).
Every video should have its textual or audio alternative, accessible for the person visiting our website.
In order for blind people to fully benefit from video recordings, these should have an audio alternative that includes words and descriptions of events from the screen.
1.3: Possibility to adapt – appropriate (understandable) presentation of the content
Everyone should be able to navigate themselves on our website in an easy and intuitive way.
All reports and information about the structure as well as the content of the website itself should be accessible from a screen reader or exist in the form of text. Properly used tags for HTML (labels, buttons, links, etc.) and aria attributes will be particularly helpful here.
The order of elements under all conditions (e. g. with JS and/or CSS disabled) must be as originally intended.
All elements available to use for the user must be understandable without information about their appearance (colours, fonts, icons used, sizes, etc.).
It comes in useful for providing an understandable description, accessible from screen readers and other supporting programmes.
The website is displayed correctly in a vertical and horizontal orientation (on mobile phones, tablets and computers).
This applies to form fields. They should have their types and values of the autocomplete=”” attribute properly established in order to have their automatic fill-in always working correctly.
1.4: Distinguishability – facilitating the perception of content
Most sites consist mainly of text. Therefore, it would be a crime to make it unreadable!
Colour can’t be the only medium for a given piece of information, and the page itself must be understandable without displaying colours.
For example, just a red border around an incorrectly filled field in a form would not meet this recommendation.
If there is an audio recording on the page and it automatically turns on for more than 3 seconds, it needs to have controls to regulate the volume, stop or turn off the recording.
Virtually all elements on a page must have a contrast ratio of at least 4.5:1. This does not apply to large texts (where the minimum contrast is 3:1), ornaments and the website logo.
Text on the page can be increased up to 200% without losing readability and functionality.
Using text in the form of a graphic, instead of real text written in HTML, should almost never happen. The exception to this would be the logo and text which must be in graphic form to retain the original meaning.
Page content within the default size, as well as when zoomed to 400%, cannot scroll horizontally (or vice versa, vertically, when the default scrolling method for a given site is horizontal scrolling).
Interface elements and graphics must maintain a contrast ratio of at least 3:1.
I’ll repeat myself in case you didn’t review specific points one by one ✨ To check the contrast of elements on the page you’re creating, you can use the developer tools in Chrome (and Chromium-based browsers) and Firefox.
The spacing between letters in the text are as follows:
- Line height – at least 1.5 times the font size;
- Paragraph spacing – at least 2 times the font size;
- A gap between letters – at least 0.12 font size;
- Word spacing – at least 0.16 font size.
Content that shows up when an element is hovered over or given focus (such as tooltips or dropdowns in page navigation) must be:
- Possible to close without moving the cursor or moving focus to another item (e.g. using the esc key on the keyboard). Exceptions to this would be error messages and content that does not overshadow other content;
- Visible when hovering over the calling content and when hovering over the called content. For example, when hovering over a word shows an additional tooltip, that tooltip should also be visible when hovering the mouse over itself;
- Visible all the time, until you remove the hover, change the focus, or close the additional information in some other way (given according to point one).
Requirement 2: Functionality
2.1: Keyboard accessibility
Using a keyboard should be as easy and comfortable as using a mouse.
The entire site is as functional from the keyboard as it is from a mouse, trackpad or another pointing tool.
If we are able to get into a place using the keyboard, then we must also be able to get out of it using the keyboard.
If there are keyboard shortcuts on the site that are triggered by a single key on the keyboard, the shortcut can be:
- switched off;
- switched over to
- or enabled only if the component to which the shortcut applies has focus on it.
One of these three must be true.
2.2: Enough time
We should be able to control animations and elements and sub-pages displayed with a time limit.
If a certain content is time-limited and this limitation is not relevant from the functional point of view (because it is, for example, the time until the end of the offer or auction), then the specific time limitation should be possible to disable, extend or adjust.
An additional exception to this is the time limits, which exceed 20 hours.
All animations on the page (flickering, moving or appearing elements) that:
- happen automatically;
- last more than 5 seconds;
- run alongside other elements, are possible to disable or hide.
The exception, of course, is a situation where animation is necessary to preserve the meaning of the content in question.
The same is true for the automatic updating of items. When it turns on automatically and happens alongside other content, the user has the option to simply turn it off.
2.3: Epileptic seizures – flashing
Specific information on how to care for people with epilepsy using the site.
Nothing on the website can flash more than 3 times per second. This applies to arbitrary and red flashes.
2.4: Ability to navigate
There should be so-called ‘skip-links’ on the page:
- At the beginning of each sub-page, leading to the main content or including links to all sections on the page within it;
- With repetitive elements – leading to the end of a specific element.
Additionally, specific sections on the page should be grouped using, for example:
- Attributes aria;
- Headings at the beginning of each section.
All subpages have titles that briefly tell about their purpose and content (this is the <title> tag).
The order of focus (e.g., using the tab key on a keyboard) should reflect the logical order of content on a web page.
You’ll find the tabindex attribute useful here, especially for pages with more advanced CSS.
In short, we can say that the text of each link on the page should describe what is under the link.
At least 2 of the following ways, must be used to link to other places on the site:
- standard links, used in the context of the element;
- table of contents;
- site map;
- search engine;
- list of links to other websites;
- links to all subpages on the home page.
Headings and labels must describe the content well.
The focus of items, when navigating with the keyboard, must always be visible.
If you don’t know how to create a focus effect that only shows when navigating with the keyboard, you can take a look at my blog article: 3 ways to make focus visible only when navigating with the keyboard.
2.5: Data entry methods
A bit about alternative ways to enter data and integrate with the site.
Anything that is gesture-operated (for which we use multiple fingers) or requires us to move our finger in a particular way, must offer an alternative way of operation for which a simple click is sufficient.
For example, a map that can be zoomed in and out with a “pinch” must contain “+” and “-” buttons to do the same.
Any action that we can trigger with a simple one-point touch must be interruptible. And if cancelling is not possible (because, for example, an action happens instantaneously), then the default state of the element affected by that action must be restorable.
Attributes used for accessible description of elements (e.g. aria-label and aria-labelledby) should contain texts or preserve the sense of texts presented visually (e.g. in form field labels or headers).
A good practice is to use the same sentences for visible labels and sentences in strictly accessibility-related attributes, or to start the latter with the former. For example, a search engine, described by the label “Search”, in the aria attribute can be described by the sentence “Search for content of interest”.
If a particular component on the page reacts to a motion by default, then this reaction should be possible to turn off, and the component itself should be possible to operate also without using motion (unless it is always necessary to maintain functionality).
Requirement 3: Comprehensibility
Languages should be clearly defined!
For other items, such as PDF files, there are corresponding techniques, which you can always read about in the link from the header ✨
If there are fragments in other languages than the language set for the whole page, they must also be marked accordingly (e.g. with the lang attribute in the HTML).
The worst thing we can do to users (especially those with limited capabilities) is to write a site that is unpredictable.
Once an element is focused, it cannot behave unexpectedly. For example, open a new tab (without warning), submit a form or change the page content.
Data entry in forms should not change the context (for example submit a form) without explicit instruction from the user (unless they have been informed of what will happen before using the component).
The navigation should not change within the site (unless the user has the ability to change it themselves).
If there are several components on a page that perform the same or similar action, they must have consistent (this does not mean identical) names, labels, and alternative texts.
3.3: Assistance in entering information
A bit about forms and their validation.
When a user fills in a form field incorrectly, they will receive accurate information about the error and which field contains the wrong data.
All forms, as well as the fields of these forms, are adequately described with instructions and labels.
If it is known how a user can correct a typing error, then a suggestion for such correction should be displayed.
If the data that the user enters on the site is of a legal or financial nature or modifies their data in a particular system, then it must be possible to restore the previous data or check it before submitting.
Alternatively, the system into which the data itself is entered may check it automatically and allow the user or user to make corrections.
Requirement 4: Compatibility
And finally, 3 general rules to force us to write good HTML (and very well).
This rule simply states that the HTML of a page must be written correctly. Its validation should be error-free and all tags are to be used according to their purpose.
A general point stating that all interface elements (buttons, links, form fields, etc.) should be correctly described with:
- aria-label and aria-labelledby attributes;
- alternative texts;
- title attributes (e.g. for iframe elements).
If the state of the application changes in some way (for example, a user-filled form throws errors), the state change messages should be encapsulated in elements with role attributes. Thanks to this, when a given element appears on the page, a user using e.g. a screen reader will immediately get information about it.
And that will be all
That’s how we got to the end – you now know exactly what should be on a website that is supposed to be compliant with the Web and Mobile Accessibility Act 🎉
If you found this article valuable or think something else should be included, be sure to let us know.
Sources not previously linked:
- Text of the Act
- Web Content Accessibility Guidelines (WCAG) 2.2 – English version of the documentation
- Wytyczne dla dostępności treści internetowych (WCAG) 2.1 – Polish version of the docuentation