Websites and mobile applications accessibility act – what needs to be implemented in order to make your website meet its policy?

  • Marketing

The websites and mobile applications accessibility act from the 4th of April 2019 is something that each public institution (theatre, museum, office, etc.) needs to take into consideration when commissioning the development of their own website.

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:

  1. 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;
  2. 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;
  3. 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:

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:


Hi, I’m Andrzej, the CEO of Brave New. We've delivered more than 300 projects for 120 satisfied customers from all around world. This year we plan to deliver 50 projects for more than 20 clients.

Looking for reliable and confidential partner for your website projects?