How to Use the 80/20 Rule in Web Accessibility?
When a website or application is accessible, it is usable by as many people as possible, including children and the elderly, people with disabilities and older devices. Unfortunately, Estonian websites are mostly not accessible, which means that they are uncomfortable or even impossible to use for many people.
Web accessibility is a big and important topic which may seem complicated at first. The accessibility requirements set out in the European Union directive mean that websites, applications and digital documents must conform to EN 301 549 standard, that is essentially WCAG 2.1 standard on level AA.
This requirement applies to the public sector from 2019 and to websites and mobile apps for products and services from 2025. It is wise to start investing in accessibility today! Improving accessibility is cheaper when done, among other regular web updates or when creating an entirely new website.
For level AA conformance, the website must satisfy 50 different success criteria, which at first glance may induce panic in both the product owner and the development team.
It's hard to go from zero to fully accessible in one go, but is there a way here to use the famous Pareto principle, or the 80/20 rule? Which are the 20% of WCAG criteria that can fix most of the popular accessibility problems?Here are 10 most critical criteria that you could start from when improving your website's accessibility.
1. Parsing
Valid HTML is the cornerstone of any good website. Using HTML5 and validating code can prevent mistakes that may disturb the assistive technology used by people with disabilities.
For example:
- incomplete start or end tags
- wrong nesting of elements
- duplicate IDs
- duplicate attributes
What to do?
Validate HTML using this tool. If the code is not valid, fix the found mistakes.
2. Keyboard
People with motoric disabilities, as well as the elderly, may have trouble using the mouse precisely. Your website must be operable also without the mouse, using only the keyboard.
What to do?
Open the website and start clicking the Tab key. Can you move onto each link, button, form field and menu element? You must be able to Tab onto anything clickable. Then, try if you can use the Enter key to activate the link, button, etc. If you can't, there's probably some custom elements in use that do not have keyboard support and must be corrected.
3. Visible Focus
When navigating with the keyboard, it is essential for the user always to see which element they are on. Otherwise, it is hard to predict what will be activated when clicking Enter. It is important to style elements differently when they are in focus – for example, with a box around it.
Screenshot 1 - On Eesti.ee, the focused link is marked with a box around it.
What to do?
Check if you can always see the focused element when moving through the page with Tab. If you can't see where the focus is, or it disappears from time to time, it is likely that the focus styles are turned off in code and must be fixed. Also, check that the focus moves in a logical (reading) order.
4. Skip Links
You probably already realised, using the keyboard to navigate, how many times you have to hit Tab to reach a particular link or button on the page. Since you have to Tab through the header and menu sections every time you go to a new page, it can take 20-50 Tab clicks to get to the actual content of the page. To save users from unnecessary tabbing, we have to add a link to the top of every page that skips user to the main content.
Screenshot 2 – On the Ministry of Economic Affairs and Communications' website, skip link pops up in the top left corner of the page on the first Tab.
What to do?
Refresh the page and click Tab. Does a "Skip to main content" link pop up (link name can be different)? If not, it must be added.
5. Page Title
Page titles are displayed on the browser tabs. It helps users understand, without opening the page and reading the contents, what the page is about. The browser can have tens of pages open at the same time, which means the tabs get pretty narrow and no longer fit the entire title. That's why it's essential to start the page title with the most important and descriptive word, not the name of the company, for example.
Screenshot 3 – The page titles of the Ministry of Economic Affairs and Communications' website start with the most descriptive word.
What to do?
Open several pages of the same website in one browser window and check the tabs to see if they all have different titles that start with the most important word. If the titles are identical or missing completely (then the page address is shown on the Tab), the <title> tags of the pages must be corrected.
6. Language of the Page
Blind people use websites on their computers and smartphones using screenreaders – software that reads out everything on the page. Screenreaders depend mainly on how well the website is built. For them to know which pronunciation to use, the language code must be set at the beginning of the code. Believe me, hearing an Estonian website in English pronunciation is pretty disturbing. Correct language code also optimises the page for search engines.
What to do?
Inspect the website and check that the language code in the beginning of the page is <html lang="en"> for English, lang="et" for Estonian, lang="ru" for Russian etc. For multilingual pages, make sure the language code changes accordingly.
7. Info and Relationships
For screen readers used by the blind, it is important that details and relationships aren't only presented visually, but also marked up in code.
For example:
- though we make headings bigger and bolder visually, we must also mark them as headings in code (H1, H2, H3 etc.);
- though we use colour to mark the header cells of the table, we must also mark them in code;
- though we place the form field close to its label visually, we must also connect them in code;
- though we mark mandatory fields with a star, we must also write the explanation for it before the fields: "Mandatory fields are marked with a star *";
- though we add fun dots or dashed in front of the list items, we must also mark it as a list in code.
What to do?
Many of these mistakes come from content editing. Make sure content editors know how to use correct heading and list styles, mark the column and row headers of tables and so on.
8. Name, Role, Value
Assistive tech, like screenreaders and speech input, rely on the information that's available in code. We strongly advise to always use standard HTML5 elements (<a>, <button>, <h1>, <ul>, <table> etc) whenever possible because they have accessibility pretty much built-in. If developers create custom user interface components, they must do some extra work.
What to do?
If the website uses custom user interface components, the developers must ensure that the name, role and value of the component are accessible from code. For example, a custom "Agree with terms and conditions" checkbox must have a name "Agree with terms and conditions", role "checkbox" and value "checked" or "unchecked".
9. Text Alternatives
Today, image recognition technology isn't at the stage yet where it could accurately and in enough detail describe images for the blind. For now, we need to add text alternatives to all important images, icons, graphs, etc. For example, a question mark icon would have alt="Help" in code which is not visible but is readable for the assistive technologies. "Alt" texts are also helpful when images don't get loaded because of connection issues and are also good for SEO.
Purely decorative images can also be "hidden" from screenreaders by adding empty alt="". But "alt" can never be removed entirely because then the screen reader will read out the file name (something like 1020-640-image-raster-50-40.jpg) which is annoying and unnecessary info for the user.
Screenshot 4 – If images are disabled on the website of the Ministry of Social Affairs, the logo's text alternative is visible.
What to do?
Turn images off in browser's settings and check if text alternatives are shown instead of images. You can also inspect a certain image (like the logo) and check that it has alt="Cats and dogs" attribute that accurately describes the image. Make sure that the content editors know how to add text alternatives to images that they upload.
10. Labels or Instructions
Clarity and simplicity are the cornerstones of accessibility. Keep texts short and concrete, so that even an older person or a child could understand them. When it comes to forms, explain in enough detail what is expected from the user. For instance, if the date needs to be entered in a particular format, let the user know beforehand. If there are specific rules for passwords, for example, they need to have a minimum of 8 characters, write this info out as well.
Screenshot 5 – Input fields on Reisi Targalt website have labels "Name" and "Last name". It is easy to make a mistake by writing your full name in the first field and then your last name in the second field again. It would be better to name the first field "First name".
What to do?
Check if each form field has a label that is visually connected to it (closer to it than to other fields) and says clearly what needs to be written in there.
Conclusion
Allowing everybody to use the web, regardless of their age and capabilities, is a part of providing equal possibilities to us all. To conform to web accessibility standard WCAG 2.1 level AA, the website must satisfy 50 criteria which may sound like a huge effort. But accessibility problems cannot be ignored, and we must find clever ways to incorporate accessibility investments into regular web updates.
