Ashley Sheridan​.co.uk

Tags:

The European Accessibility Act enters the enforcment stage on the 28th of June, giving website owners and maintainers just slightly over a week to make their websites and services compliant, or risk fines, sanctions, or even outright bans, depending on the severity of the non-compliance.

Contents

What is the EAA?

The European Accessibility Act (EAA) is a law put into place about 6 years ago to enhance and replace existing accessibility laws, and fill in gaps where laws didn't exist already. I wrote about how the EAA functions back in November of last year, but given the very pressing timeline for the enforcement stage coming up, and with some details made clearer, I felt it would be a good time to go back over some things.

At its heart, the EAA will affect websites and services that cater to people living in the EU and UK, regardless of where that service actually is. So, a website in USA selling products to customers in the Germany falls under this just as much as a bank in the UK serving French customers.

What is Covered?

Here is the basic shortlist of what is actually covered (I have more detail in my previous article should you want to find out more):

• Computers and smartphones, and their operating systems.
• Cash machines, ticket and payment machines, and check-in machines.
• Transport systems
• E-books
• Banking and financial services
• E-commerce services
• TV and broadcasting

As you can see, the scope is quite large, and covers a whole lot. If you're unsure, it's never a bad idea to try and build your websites accessibly anyway. But, if you're a website that offers a paid service, or you offer some form of broadcast media (like live streams for example), and you have users in the EU/UK, then you fall under the EAA.

How to Report Issues

There are 2 main ways that issues may be found and reported. One is through a manual report being made, and the second is that a monitoring authority performs some form of audit on your website/service.

User Reports

If a user finds an issue, the first point of call for them should be to look for that websites accessibility statement which should highlight how to best get in touch with the right person to effectively document the issue and help them get it fixed. This may be an online form, or something as simple as an email address which you can report issues to. You may have a different timeline to respond to issues reported in this manner depending on the location of the user making the report. While the response times vary, I would instead recommend using the minimum as the baseline, in order to ensure you're both covered and giving the best experience to your users as possible. In all cases, once a user reports an issue, you must update your accessibility statement with details of this, and your planned remediation steps.

Here are some of the countries involved along with their required response times and what you can do as a next action if your report is ignored or not responded to within the required timeframe:

If an issue makes it to the stage of being reported to official channels, then you will typically have 90 days to address said issues, or at least make a good faith effort to fix them. Whilst updating your accessibility statement is such a step to that end, a better one would include at least a partial fix.

Automated Audits

The second method for an accessibility issue being reported is via an audit, which may typically be performed automatically.

There is a subtle difference with these types of reports, as the EAA focuses on actual non-complicance. In other words, some issues found may be false positives, and don't actually cause a real issue for a real person. For example, a large image may have an empty alt attribute but contains a caption with a link to a more accessible text version. This sort of thing could be picked up by automatic processes which are unable to associate the accessible content correctly.

However, if an automated process finds your service contains a toolbar with dozens of image buttons but no proper text labels, that would still be an accessibility issue that needs to be resolved within the reporting countries timeframe, despite a real person not manually making the report.

Getting Ahead of Issues

Obviously, you don't want to be fighting fires when it comes to accessibility. It's much better to be aware of what the issues are and build in processes that can help ensure they don't occur for your users.

What are the Most Common Issues?

The WebAIM One Million project has been documenting accessibility issues on the most popular websites for the last 6 years. They list the top issues as:

These are all easily detectable issues, and thankfully, fairly easy to resolve.

Colour Contrast

Poor colour contrast is quite a wide reaching issue, and can cause problems for people with colour blindness, low vision, or just those in bad lighting conditions. The WCAG 2.0 level AA requirements specify that you should have a colour contrast of at least 4.5:1 for normal text, and at least 3:1 for large text. If you're unsure of what that means, WebAIM has a great colour contrast checker tool that can help check contrast not just for text, but for graphical elements as well.

Missing alt Text

There are two types of images you will use on the web: content and presentational. For presentational images, it's typically enough to give the image an empty alt attribute, but it's considered better to do something like this:

This tells the browser to completely omit this from the accessibility tree it creates.

However, if your image is for content purposes (e.g. a photo showing the number of people at an event, or a picture of a finished product) then it should be given appropriate text as an accessible label.

There are a few things to remember for this:

• Leave out unnecessary words like "image of" or "photo of", as these add nothing and arer effectively just repetititve.
• Images of text should ideally just have their alt set to the text in the image. A common mistake I see if with image logos, which have an alt of something like "ACME Inc logo". The word logo there is not needed (unless that word does actually exist in the image itself).
• Try to catch automated alt text values. Some automated processes might just use the image file name there, which won't always get detected by an accessibility tool.
• A description of an image isn't always the best for alt text. This is a popular mistake I see when AI tools have been left to generate alt text. Consider why the image is there, and what message it's trying to convey. If the image doesn't load, for example, would the description make sense when read out, or does it completely detract from the reading flow?

Missing Labels

There are many types of labels that can be used for various parts of your websites:

Form Labels

Whilst form elements themselves should each have an accessible label, there are other ways to label parts of your form as well. Consider the following when checking your forms:

• Every form element needs an accessible label. Common mistakes I see here are:
  • Labels not correctly associated with their <input>s using an id and for attribute. Having a <label> tag just near a form field does not magically link the two!
  • <input> tags using the placeholder as a form label. This creates a situation where a field with a single character value has no visible label, which can lead to confusion for some users if they were to be interrupted during the process of filling it out.
  • Every individual radio button and checkbox needs it own label.
  • <select> lists are also form elements, and need a visible label. You cannot just rely on using the first element as a label.
• It's good practice to label the form itself. Typically a form would have some kind of visible heading or text. By giving this an id, you can use aria-labelledby to associate that text with the form. This means that the form will show up as a named landmark area, which allows screen reader users to navigate to it more easily.
• Consider grouping form elements where appropriate using <fieldset> and <legend>. These create a hierchical structure for those elements for better navigation by some assistive tech.

Landmark Areas

On the topic of landmark areas, it's a good idea become more familiar with landmark roles and use them to label parts of your page better. Tools such as screen readers allow a user to jump to named landmark areas of a page quickly, without requiring them to tab through an entire page.

Links

Link text should be descriptive of what content it links to. A link that just reads "click here" means nothing:

Empty Links

As well as poor link text, empty link text is a big problem. Typically this occurs when a link is around some visual element that itself has no text label, such as an image with missing alt text. Running basic browser tools (like those built into Firefox) is an easy way to catch these issues.

Empty Buttons

This is typically found when a button contains some kind of visual element that has no text alternative, like an image button or a <button> element containing an image or SVG. Of the two types, I'd recommend using <button> as it's far easier to make it more accessible:

Missing Language Declarations

This is one of the easiest to fix, and is as simple as adding a lang attribute to your <html> tag. But, by telling the browser what language your content is in, it doesn't have to make assumptions based on the content. Sometimes, these guesses can be very wrong, and change from browser to browser.

If your website uses mixed language pages (by that I mean, pages with content in more than one language on the same page, not pages offered up in more than one language) then you can use the lang attribute on the element that contains the content that's in a different locale from the document. For example, imagine a news website in Spain that has a quote from someone in the UK. While the main language of the page would use lang="es-ES", the quote would use lang="en-GB".

Non-Compliance Penalties

Failure to be seen to perform any kind of remedial steps can result in fines ranging from €5,000 with the possibility to go all the way up to €1,000,000! The likelihood is that fines will be set according to the severity of the issues, and the effort (or lack thereof) to resolve them. Various member states within the EU have set their own fine limits that correspond to the seriousness of the problem.

However, beyond the fines, sanctions or full on blocks can be places on products and services that are not compliant with the EAA, which could actually result in a far greater financial loss than the maximum fine. Again, I should stress that this is going to be the last resort, after all other actions have failed. I would hope that nothing reaches this stage!

Conclusion

So, while the repurcussions seem scary, the reality is that a lot of issues can be fairly easily fixed, and as long as you have a well documented process outlined in your accessibility statement, you are unlikely to be hit by fines or worse, as long as you continue to show a good faith effort to resolve issues.

Put accessibility testing in place as part of your release process. Create a simple risk matrix that for issues that you find to help give them a severity, and use that to help create the order in which you tackle them. Document your process, your known issues, and timelines on yuor accessibility statement.

Lastly, remember that accessibility is not just a one-time thing. Over time, new things may be found, guidelines may change, and you will need to adapt to this. Build in the accessibility efforts throughout your process, whether it's thinking about colour contrast during the design stage, considering the complexity of copy during the content creation phase, or using semantic markup during development. Find an accessibility advocate in your company who can help champion the cause and use internal documentation to provide access to helpful tools for all members of your teams.