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
1.1.1: Non-textual content
All non-textual content (images, videos, multimedia and interactive elements, etc.) should have a textual alternative that describes its:
- purpose;
- way of working;
- or performs the exact same function (in the case of buttons).
You will find alt, title, aria attributes particularly useful here, but also media alternatives themselves, such as transcriptions of recordings, for example.
1.2: Accessibility of time-varying media
In short – media based on senses cannot rely on only one of them.
1.2.1: Only audio and only video (recording)
Audio or video elements should have their textual alternatives or audio descriptions showing the exact same content as the original multimedium.
1.2.2: Extended subtitles (recording)
All recordings consisting of both audio and video should have subtitles containing descriptions of all the significant sounds from the extract (noises, dialogues, etc.).
1.2.3: Audio description or an alternative for media (recording)
Every video should have its textual or audio alternative, accessible for the person visiting our website.
1.2.4: Audio description (recording)
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.
1.3.1: Information and reports
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.
1.3.2: Understandable ordering
The order of elements under all conditions (e. g. with JS and/or CSS disabled) must be as originally intended.
You need to be careful with copying the same elements and changing their order with the use of CSS or JavaScript.
1.3.3: Sensory properties
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.
1.3.4: Orientation – displaying of the content in horizontal and vertical view
The website is displayed correctly in a vertical and horizontal orientation (on mobile phones, tablets and computers).
1.3.5: Identifying correct value
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!
1.4.1: Use of colour
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.
1.4.2: Audio playback control
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.
1.4.3: Contrast (minimal)
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.
To check the contrast of the elements on the page you are creating, you can use the developer tools in Chrome (and Chromium-based browsers) and Firefox.
1.4.4: Changing text size
Text on the page can be increased up to 200% without losing readability and functionality.
1.4.5: Text in the form of graphics
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.
1.4.10: Wrapping text
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).
1.4.11: Contrast for non-text content
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.
1.4.12: Text spacing
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.
1.4.13: Content from under the cursor or focus
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.
2.1.1: Keyboard
The entire site is as functional from the keyboard as it is from a mouse, trackpad or another pointing tool.
2.1.2: No keyboard trap
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.
2.1.4: Single letter shortcuts
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.
2.2.1: Ability to adjust the time
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.
2.2.2: Pause, stop, hide
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.
2.3.1: Three flashes or values below the threshold
Nothing on the website can flash more than 3 times per second. This applies to arbitrary and red flashes.
2.4: Ability to navigate
2.4.1: Ability to skip blocks
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.
2.4.2: Page titles
All subpages have titles that briefly tell about their purpose and content (this is the <title> tag).
2.4.3: Focus sequence
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.
2.4.4: Purpose of the link (in context)
In short, we can say that the text of each link on the page should describe what is under the link.
For poorly described or unclear links, you’ll definitely find aria attributes useful, especially aria-label and aria-labelledby, and alts for non-text elements.
2.4.5: Many ways to locate a site
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.
2.4.6: Headings and labels
Headings and labels must describe the content well.
2.4.7: Visible focus
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.
2.5.1: Spot gestures
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.
2.5.2: Cancelling a click
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.
2.5.3: Label in the name
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”.
2.5.4: Activating with movement
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
3.1: Readability
Languages should be clearly defined!
3.1.1: Page language
The lang attribute for the <html> element must be correctly defined, as appropriate for the language in which the main content on the page is displayed.
For other items, such as PDF files, there are corresponding techniques, which you can always read about in the link from the header ✨
3.1.2: Language of the parts
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).
3.2: Predictability
The worst thing we can do to users (especially those with limited capabilities) is to write a site that is unpredictable.
3.2.1: After the focus mark
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.
3.2.2: When entering data
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).
3.2.3: Consistent navigation
The navigation should not change within the site (unless the user has the ability to change it themselves).
3.2.4: Consistent identification
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.
3.3.1: Identification of error
When a user fills in a form field incorrectly, they will receive accurate information about the error and which field contains the wrong data.
3.3.2: Labels or instructions
All forms, as well as the fields of these forms, are adequately described with instructions and labels.
3.3.3: Suggestions for correcting errors
If it is known how a user can correct a typing error, then a suggestion for such correction should be displayed.
3.3.4: Preventing errors (legal context, financial, related to the provision of data)
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
4.1: Compatibility
And finally, 3 general rules to force us to write good HTML (and very well).
4.1.1: Parsing
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.
4.1.2: Name, role, value
A general point stating that all interface elements (buttons, links, form fields, etc.) should be correctly described with:
- labels;
- aria-label and aria-labelledby attributes;
- alternative texts;
- title attributes (e.g. for iframe elements).
4.1.3: Status messages
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.
The attributes role=”alert”, role=”log”, role=”status” and others will be useful here.
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
- LepszyWeb.pl
- 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