Accessibility News - September
This month’s accessibility news highlights ongoing challenges and important standards updates, from widespread accessibility issues in HTML emails to changes in Europe’s EN 301 549 standard. We also look at W3C’s updated ARIA in HTML Recommendation and what the changes mean for using ARIA with HTML elements.
Survey find no improvement in email accessibility
The Email Markup Consortium has released its 2026 Email Accessibility Report, analysing 376,348 HTML emails collected between May 2025 and May 2026. The results show little overall improvement from the previous year, with 99.88% of emails containing at least one accessibility issue categorised as Serious or Critical. Just eight emails, or 0.002% of those analysed, passed all of the report's automated accessibility checks.
Many of the most common issues were relatively fundamental accessibility issues, causing a range of issues for those using assistive technologies in particular. Some of the main issues detected included:
- Missing language attributes within the email, impacting the way assistive technology announces email content (95%)
- Tables not being correctly identified as layout tables (83.78%)
- Links without clear and understandable link text or linked images without sufficient text alternative (71.23%)
- Text with insufficient colour contrast (58.48%).
Almost half, 47.88%, contained images without alternative text. While several of these measures have improved compared with previous years, the report describes the overall rate of Serious and Critical issues as largely unchanged.
Of note, this year the report also examined the role of the common tools used to create emails. More than 10,500 emails sent through Substack, Shopify and Beehiiv were assessed, with none passing the testing undertaken.
It is important to note that these results cannot necessarily be attributed entirely to the platforms, as some issues may result from choices made by authors, however the report argues email-building platforms have an important role in guiding people towards more accessible content.
Email clients present another challenge. The report assessed support for 37 HTML and CSS features that can help developers create accessible email, and found that none of the 43 email clients tested supported all of them.
Apple Mail on macOS performed strongest with support for 34 of 37 features, while 25 of the 43 clients supported fewer than half. The report concludes that improving email accessibility requires shared responsibility across senders, email-building platforms and the clients that ultimately render messages.
Read the full 2026 Email Accessibility Report.
Updates to the European accessibility standard
Europe’s key digital accessibility standard is undergoing a significant update, with EN 301 549 v4.1.0 now adopted by the relevant bodies and the final v4.1.1 expected to be published shortly. The update brings the standard into alignment with WCAG 2.2 and introduces changes designed to support the European Accessibility Act (EAA).
EN 301 549 sets accessibility requirements for a broad range of ICT, including websites, mobile applications, software, electronic documents and hardware. It has an important role in supporting European accessibility legislation and is also influential in accessibility requirements and procurement practices internationally.
One of the most significant changes is the move from WCAG 2.1 to WCAG 2.2, incorporating the six new Level A and AA success criteria introduced in WCAG 2.2. The update also significantly reworks requirements relating to User Preferences and makes changes across requirements for web content, non-web documents and software.
The updated standard has also been developed to support the European Accessibility Act. New mappings connect the requirements of EN 301 549 with the EAA, providing an important foundation for the standard's future role in demonstrating conformity with European accessibility requirements.
While EN 301 549 is a European standard, its influence extends well beyond the EU, including to Australia. It is commonly referenced in Australian government ICT procurement and accessibility requirements, particularly through AS EN 301 549, the Australian adoption of the European standard, though the Australian standard itself has not yet been updated.
Read the full updated EN 301 549 standard.
W3C finalises updates to ARIA in HTML recommendations
The World Wide Web Consortium (W3C) published an updated ARIA in HTML Recommendation last month, formally incorporating amendments that had previously been included in the specification as candidate amendments.
ARIA in HTML defines how Accessible Rich Internet Applications (ARIA) roles, states and properties can be used with HTML elements. Because many HTML elements already provide built-in accessibility semantics, adding ARIA is not always necessary or appropriate.
The Recommendation sets out which ARIA roles and attributes are permitted on particular HTML elements, where their use is not recommended, and where it is prohibited because it could conflict with native HTML semantics. It is an important reference for web developers, accessibility professionals and developers of automated accessibility and HTML conformance checking tools.
Of the finalised updates, many relate to “Naming Prohibited” rules within the Recommendation. These identify HTML elements for which authors must not use aria-label or aria-labelledby to provide an accessible name. The amendments expand the range of elements and circumstances identified as Naming Prohibited and clarify exceptions where an element's semantics can be changed to a role that supports author-provided naming.