Accessible pdf's

Recently someone asked about accessible pdf’s. Using word it is really easy. Three simple steps

The first step is to make sure your headings are good https://forestpathways.co.uk/our-videos/microsoft-word–headings

Then you need to sort out the links and remember to add the tool tips https://forestpathways.co.uk/our-videos/microsoft-word-external-links

And lastly the easiest bit, check accessibility and create the accessible pdfs https://forestpathways.co.uk/our-videos/accessible-pdfs

3 Likes

This is great information @guywoodland, thanks for sharing.

Seems it’s easy to forget that in addition to the website, all the linked resources need to be accessible too. I must admit I wouldn’t have thought about accessible PDFs. Makes me wonder what else needs to be taken into account when building a website for maximum accessibility.

There’s a whole list in the current EN 301 549 standard, and for EU-based websites it’s going to become quite a bit more extensive in the coming two years because of the European Accessibility Act (EAA). This needs to become law in all member states by 28 June 2025 and dictates the new and refreshed accessibility requirements and also expands on which websites will need to become accessible by law.

Here’s some of the requirements as dictated by this act:

  • a visitor needs to be able to disable animations and other possible triggers, including pop-ups(!) [1]
  • the background colour(s) and the text colour(s) need to either be in a contrast to each other, or the site will need to provide a switch that creates this contrast
  • text needs to be scalable
  • keyboard navigation is mandatory
  • entry fields need to be screen readable by software and navigatable by keyboard.

As for externally created sources:

  • videos need to be subtitled in at least the language that is spoken in the video (others are optional);
  • documents that form an integral part of the site (like a PDF that you load in a frame, but any other document that you load into view falls into this category) need to be accessible in the same way as your website. This excludes downloadable files as I understand it;
  • audio files that form a part of your website, excluding music, need to be transcribed.

All this is only mandatory for websites in the following domains though:

  • Websites that offer, or are run by companies that offer, electronic communication to consumers;
  • Websites that offer audiovisual services of any kind to consumers;
  • Websites that offer, or are run by companies that offer transport- or travel services by air, road or rail;
  • Websites run by companies that offer financial products of any kind to consumers;
  • Websites that offer e-books and/or software related to e-books to consumers;
  • Websites that offer e-commerce to consumers.

You can be exempted from compliance in your local member state if your company’s annual turn over is below a set point. Member states can set that point themselves.

[1] I’m currently trying to find out what this means for privacy pop-ups

Cheers,
Erwin

3 Likes

More great information, thanks @Heroic_Nonsense for sharing.

We could probably have a whole forum section dedicated to accessibility it seems with the current and coming regulations/laws.

This will probably spawn some pretty good opportunities for freelancers/companies to offer accessibility products and services to help people make sure their websites are in compliance, and bring them up to compliance if not.

You have been warned, don’t use widgets

In Europe they are already ruled as banned and this little Video shows you why a screen reader will struggle

It’s slightly like website privacy. Most of EN 301 549 is easy to implement and fairly common sense. Things we’ve been (or should have been) doing for some years already. As always there will be a sizeable proportion who claim it does not apply to them. Equally so, I think a lot of RW users will be comfortable with making small changes towards compliance.

As always, this is where it pays dividends to invest into quality addons and software. Rather than just the copy cat, get-rich-quick clones from developers that don’t know anything about what they’re making!

@Heroic_Nonsense To help you with point #1 in my client websites I have been adding this CSS:

@media (prefers-reduced-motion) {
  *,
  *::before,
  *::after {
    transition: none;
    opacity: 1;
  }
}

If a website user has their browser set to the prefers-reduced-motion flag, then this code disables every CSS transition on every page element.

How it works:
The *, *::before, and *::after selectors target all elements and their pseudo-elements on the page. This ensures that the transition effects are disabled universally, affecting all elements and any content generated before or after them. Opacity set to 1 ensures any elements you had starting from a hidden (or partially hidden) state are visible and don’t dim or fade on hover, active or focus. This code works good for switching off any CSS animations (for those wanting no animations) and is a good starting point. Expand it, as you see fit.

I know for a fact that popups are not banned under EN 301 549. But you can do something like the above to disable animations on them, so they snap instantly in and out of view. Just make sure any popup or lightbox returns mouse focus back to the element that was originally focused (if applicable). Most newer ones do, but some don’t. Lightboxes and slideshows might be the biggest “gotchas” RW folks run into with accessibility compliance.

Although a fair chunk of EN 301 549 applies to the web, a large proportion is directed towards mobile and desktop operating systems. Hence in the Linux community, we have seen a progressive shift from the old X11 windowing system to Wayland. The Sovereign Tech Fund wrote a cheque to the GNOME desktop environment last year for €1 million to fund a lot of research and development into accessibility for Linux derived desktops and smartphones. We can expect Google, Apple and Microsoft to be allocating more budget towards accessibility too.

Thanks for the CSS, Will!

EN 301 549 indeed doesn’t ban pop-ups, but the new legislation expands on EN 301 549.

And pop-ups aren’t banned as I understand it - it’s just that visitors would need to be able to switch them off. I’m actually not entirely sure if this means all pop-ups, including for instance the cookie alert and modals that are triggered by the visitor themselves, or just the pop-ups that open automatically when you mouse away from the viewport (ugh… those are annoying) or are timed.

I’m hoping to get a bit more info about EAA next week, and hopefully this will be made clear.

Cheers,
Erwin

Hi, It begins well this law on equal access: still no translation into French of the FAQ on the European Commission’s website :joy:. This will not concern companies with less than 11 employees with a turnover of less than two million euros. Many Youtubers can catch their breath… :face_with_open_eyes_and_hand_over_mouth: I have been working for 30 years in the mental disability sector, I have been putting in place since 2001 all the new accessibility rules… I hope that with the one that seems to want to continue in my retirement :partying_face:, I will finally see a real improvement for the beneficiaries… I am also used to seeing decisions change at the last minute. November 2003: mandatory air conditioning for all fragile people housed in institutions. Since… at least one air-conditioned room in each institution… if possible. It’s so beautiful that they did the same thing again with the mandatory standards of elevators… always under derogation :rofl: Maybe samething here…

A good article

Joint statement on accessibility overlays

Like with privacy, I suspect there will be an element of “is this essential, yes or no” towards popups.

A popup that is fundamental to navigating the website, setting preferences or accessing content is likely to get prescience, in comparison to something annoying (like an email signup) that is actively breaking website accessibility and is deemed non-essential to the user experience.

Used in moderation, popups can be made to be very accessible. The HTML spec now includes the dialog property that is gaining good support, as a native means of showing content inside popups with minimal code and accessibility problems.

The replacement to MiniCookie uses this. :wink:

1 Like

And another European Accessibility Act

@guywoodland thanks for that last link - it’s always nice to have a visual explanation fro those who score in that Kolb quadrant :wink:

As for overlays - the EAA doesn’t propose overlays. It merely states that affected websites need to offer a predefined set of accessibility measures to visitors, not how. For example, triggers (like animations and pop-ups) fall into the category of “harmful to people with photosensitivity and epilepsy”, and your site should offer a way to switch them off (like @willwood said - this likely applies to certain kinds of pop-ups only though, as others are mandatory as a result from other European directives).

EDF advocates out-of-the-box accessibility compatibility instead of relying on a toolbar with settings. They’re saying that the toolbars that you can find on websites right now, are at the least redundant because browsers and other software offer the same functionality if the site is designed well, and in the worst case incompatible with the specialised software that disabled visitors might be using. So these overlays might make things even worse.

And they’re right: if you make a site that relies on CSS for its markup, most browsers will be able to scale the text. Also, special extensions for browsers will be able to change the colours for better contrast or the font for a better readable one (just a few examples). If you use actual text instead of images containing text, then screen readers will be able to read that text out loud. If you use well formulated alt-texts for your images, screen readers will be able to tell what the image is showing.

Although EDF has a point that most of the measures in the EAA are already part of modern browsers, and the proposed controls are therefor redundant: if the law says your site needs these controls, then your site should have these controls. Redundant or not.

And there are lots of websites that are not (well) readable by screen readers because of using images as texts, unnusual constructions for loading and formatting text and lacking or non-descriptive alt texts. The screen reader software can’t make heads or tails from these sites, and these are the sites targeted by the EAA.

Cheers
Erwin

An overlay creating problems

Regardless of legalities here is a good example of why overlays can be problematic for screen readers.