Web accessibility, monitoring rapports and how you can use them.

At the latest ERFA-meeting in the Publify development team Stein Erik Skotkjerra from Inklusio and Orla Pedersen from Inqlude IT paid us a visit and told us about the most common accessibility-mistakes, you find on websites for Danish municipalities, and how to correct the errors. Here we share their tips and recommendations.  

Inklusio and Inqlude IT are a part of the consortium, which the Danish Digitization Agency have chosen to take care of the assignment of monitoring and reporting to public authorities and bodies governed by public law. The consortium is currently testing websites and preparing reports for the organisations in question. Inklusio and Inqlude IT have established a good overview of the most common mistakes you experience during automatic and manual tests of the municipalities’ websites. They shared these experiences at the ERFA-meeting in September. Moreover, both corporations have great expertise in helping public and private corporations correct errors, so they were also able to provide advice for handling and prioritizing in the municipalities’ the following work with corrections.  

The monitoring-tests, that Inklusio and Inqlude IT make, are based on 50 so-called success criteria from WCAG 2.1 on levels A and AA. Tso calledo get verifiable results, one uses World Wide Web Consortium’s (W3C) rules for accessibility. They set the standards for World Wide Web. The rules are known as ACT rules, Accessibility Conformance Testing Rules. These are the same rules, which web accessibility tools like Siteimprove and Monsido are built upon.  

Two types of tests are made in the monitoring: Simplified and in-depth/saturating. 

The simplified tests are made automatically with the tool Qualweb. An automatic test like this is not able to find all deficiencies and defects. Only 30% of the success criteria in the monitoring can be found in automatic tests, but on the other hand, it is able to find many of the most common errors. 

The more in-depth tests are made manually on chosen sites of a solution, and Stein Erik calls them “the greatest gift”, because of the great deal, that can be learned from them. Yes, they are challenging, but the purpose of them is to optimize the web accessibility of a site, and the rapport, that comes with the test, shows what can be improved.  

Stein Erik emphasized a number of the most common and the most critical errors that Inklusio and Inqlude IT find in the monitoring of public sites. He evaluates the errors as especially important because they have an effect on larger population groups/assemblages. These are listed in the following sections, along with explanations and examples of how to identify them. 

Contrast minimum 

Contrast minimum is a leading example of one of the most common errors, which also affects many people (Success criterium 1.4.3). The contrast ratio on content, for example, between text and background, has to be a minimum of 4,5 to 1, unless the text is very large. The contrast ratio is important to people, who are visually impaired, and problems with the contrast ratio are, with a bit of practice, relatively easy to evaluate with the naked eye. 

Font sizes 

A couple of other often seen errors on municipal websites revolves around font sizes. The first one is the Change of font size (Success criterium 1.4.4), which requires that text/text size is able to be enlarged/increased up to 200% without loss of content or functionality. This is easy to test on a website by enlarging/increasing the text size on a page by clicking Control+ (on a PC) or Command+ (on a Mac) on the keyboard. The other success criteria, Wrap display (Success criterium 1.4.10), can then be tested when the text size is well enlarged/increased. Here, the text needs to be able to be read inside the screen without the use of scrolling. An error in wrap display could be if you have a long heading on your site that doesn’t break down on several lines, using either zooming or displaying on a smaller screen. 

Contrast for non-text content 

A relatively recent success criterium is requirements about contrast ratios being a minimum of 3 to 1 between graphic elements and the adjacent colours (Success criterium 1.4.11). As an example, the need for being able to evaluate whether a check box is checked can be mentioned. 

Information and relations 

To allow blind and visually impaired people to have the same possibility of orienting themselves in a layout and in the structure of a text, it is necessary that information, relations and structure, on a website can either be read with a screen reader as text or is conveyed in the programming. An example of Information and relations (Success criterium 1.3.1) is that the structure in a text with headings, subheadings and body text should be able to be presented via a screen reader as well as it can be decoded by a seeing person. As a special bonus, Stein Erik could inform that, opposed to many people’s perception, it actually isn’t a requirement for the heading structure to follow a hierarchic formation. For example, it is allowed to insert an H6-format and then an H2-format. The important thing is that the code must correspond to the visual aspect. 

Naming elements is another example of the success criterium for Information and relations: A button must have a name and not only the description ‘button’, so that one can also evaluate, if it is to perform a specific task, with a screen reader. And at last: don’t forget that namings should be possible to read in the particular language that the screen reader is using. In this way, the communication, for example, the fact that an accordion opens and closes, is clear.  

Keyboard and Direction 

All content in a web design should be possible to access and choose using only the keyboard (Success criterium 2.1.1). This is both for choosing what one wants their screen reader to read out loud, but also for users who are physically unable to work with a mouse, to be able to navigate on a page. Another hardware-related success criterium is the possibility to see content on a page on a smartphone in both vertical and horizontal directions (Success criterium 1.3.4). Direction is a need, which is seen with wheelchair users who have a smartphone hooked up to the wheelchair. 

Headings and labels 

Links with the text ‘look here’, ‘read more’ and ‘here’ are accessibility errors that are often seen on websites today. It is necessary that links and call to action buttons have headings and labels (Success criterium 2.4.6) so that users, that depend on a screen reader can understand their purpose. Stein Erik points out that headings and labels must make sense to the context, even though it can be tempting to add a fallback text in the code, that doesn’t necessarily make sense seen from a communication perspective.   

Naturally, there are many more success criteria, which are important to web accessibility, but the ones above are applicable to the broadest groups. These errors are thus the ones that can be corrected with the most immediate gain. That is why they are on the list of Inklusio and Inqlude IT’s recommended priorities in corrections. 

Stein Erik points out that their priorities are based on experience that Inklusio and Inqlude IT have achieved through their work. Still, they are not necessarily priorities that the Danish Digitalization Agency will agree with. 

Stein Erik called the monitoring a gift because it comes with a report and hence is an overview of what needs to be corrected on a website. But how does one, as a web editor in a municipality, use this gift to its full capacity? 

Stein Erik’s recommendation is not just to start from one end, but instead to go forth systematically.

One tip is to choose your 30 to 50 most visited pages and start the corrections there.

The next tip is to look after an error, that reoccurs on a component, that exists on multiple pages.

Here you can examine if this component can be made in a smarter way. Otherwise, you might have a single component, for example, the search box or a drop down-function, so that a correction of the single component will solve accessibility problems on multiple or all pages. 

Stein Erik rounded the many tips to web accessibility, and handling of reports from the Danish Digitalization Agency, off with a couple of recommendations about how to best work with the web accessibility statements, that are created with the Danish Digitalization Agency’s WAS-tool. 

Stein Erik firstly pointed out, that the web accessibility statements exist with the purpose of helping the residents. Not to help the Danish Digitalization Agency. Therefore, the information, you write in the accessibility statements, should be aimed at the residents. The information should include information about, what limitations there would be to access information on a website, and what the resident can do to access this information in another way. As an example, this could be a text like “if you cannot read this article X, then please contact Y”. 

Stein Erik recommended, that one, in contact information, always indicates both phone number and email address. Forms should be avoided, because users, who have difficulties in accessing informations on a website, also can be challenged in using an online form. Also, a phone number should always have an email address as an alternative option, because a hearing-impaired user will need that. 

An important part of the web accessibility statement is also a description of how to relate to the different existing problems with web accessibility. With a known problem one needs to describe, how one plans to solve it, and if the problem is in the category ‘disproportionate burden’, one has to argue, why it is so. 

The work with monitoring public websites is right now in its first phase, which runs over 2021 and 2022. Before initiating the next phase, in 2023, the method is to be evaluated. 

Likewise, making the WAS tool more accessible is being worked on, and an update from the Danish Digitalization Agency is expected in the fall. 

Read more about the monitoring here:   

https://digst.dk/digital-service/webtilgaengelighed/hvordan-foerer-vi-tilsyn-med-lov-om-webtilgaengelighed/monitorering/  

 See Guidelines for Accessible Webcontent (WCAG) 2.1 at:  https://www.w3.org/Translations/WCAG21-da/