W3C, the World Wide Web Consortium, released a new draft of the WAI-ARIA 1.3 specification on 23 January 2024.
If you're not familiar with it, WAI stands for the Web Accessibility Initiative, and ARIA stands for Accessible Rich Internet Applications.
It's a set of standards created to improve the accessibility of the products we build for the web, and it includes details about HTML attributes you can use to make content better for assistive technology. Some common ones you might have come across are aria-label, aria-live, and aria-describedby.
With the new draft of 1.3, we can get a bit of an idea as to what is coming, and how we can prepare for implementing and testing these features.
Many organisations seem to view accessibility through a narrow lens. They do not recognise the breadth and depth of expertise that is required to create a well rounded accessibility role.
We had a similar situation 10 to 15 years ago, when start-ups were constantly trying to hire a single person that could do visual design, user experience (UX) design and software development.
This results in bloated job adverts hunting for somebody who likely does not exist in the job market. A mythical creature. A legend. Their reputation transcends the entire industry, yet nobody has managed to find a real one. Hence the term 'unicorn'.
Web Chat relies on real time information and notifications, so you're going to need to use several features of Aria (Accessible Rich Internet Applications).
In this post, I'm going to cover in detail which of the Web Content Accessibility Guidelines (WCAG) you're going to need to consider, and some examples of how you can use advanced attributes to give screen reader users the best possible experience.
The European Accessibility Act and its impact on the private sector.
Learn the differences between the EAA, EU Accessibility Directive, Public Sector Bodies Accessibility Regulations, and EN 301 549, and discover top tips to prepare your business for compliance with the EAA.
The term ‘microservice’ is becoming more and more popular when you look across the Digital landscape of a lot of big organisations.
Several Government departments, and several large organisations I've spoken to recently, are all looking at this approach; because, if executed well, it saves time and money, and they create consistency for users.
However, as more and more organisations try to leverage microservices, the pitfalls of accessibility are perhaps not being fully considered.
What I'm really tired of, is reading conformance reports from third party suppliers who are trying to push their inaccessible products for large sums of money under the guise that it is accessible.
These chancers often state that some of the criteria is 'partially supported', 'supported with exceptions' or any number of different ways to carefully word the fact that it does not support a particular accessibility feature.
And, it's not just one company, they're all doing it.
These two criteria are important, because they help screen readers to read out the language correctly. If your page is set to English, but some of your content is not English, then the screen reader is just going to attempt to pronounce it in English anyway, which can lead to some pretty weird results.