Thanks to European directives (EU 2016/2102 and 2019/882) and their implementation in national laws, we can now say that web accessibility is getting the regulatory importance it deserves.
The public sector as well as the private sector must ensure that their products and services are built for the widest diversity of users as possible, including people with auditory, cognitive, physical, speech and hearing impairments.
Of course, this raises a lot of questions, and people in industry often find themselves struggling to find a sensible and balanced way forward – one which observes values of inclusivity, adheres to legal requirements while at the same time respects the available business and operational parameters – including budgets and knowledge. This article is not going to present an argument in favour of web accessibility – as a society, we should be way past the need for that.
There is some good news: browsers are there to help. When someone lands on a website, their browser downloads and renders all of its content and functionality according to the intended designs. However, the browser does other things in the background as well – the most relevant to this discussion is the generation of the Accessibility Tree.
Based on the underlying client-side technologies (e.g. HTML and CSS), the browser automatically generates an alternative representation of the website’s content and functionality that is specifically meant to be consumed by assistive technologies, such as screen readers or braille displays.
The Accessibility Tree contains accessibility-related information for elements on a page, including properties such as the element’s role (e.g. checkbox), state (e.g. checked), and accessible name.
This information is then communicated by the assistive technology in a way that can be perceived appropriately by its user. The caveat is that the Accessibility Tree is only as good as the developer’s work – and browsers operate with one major assumption – primarily, that client-side technologies, such as HTML, are used appropriately, adhering to well established standards while also being semantically correct.
Here is a simple recommendation: keep it simple. Don’t use clever widgets if you can use a native HTML element. If you need a button, use a native <button>.
There is some good news: browsers are there to help
If you need to organise your content under different headings, then use <h1> down to <h6>. If you want to display a list of items, use the native list elements (<ul> or <ol>).
Tabular data? You got it, use a native <table>. If your content is to be read following a certain logic (left to right, top to bottom) then avoid using clever styling to shift things around and ensure that your underlying markup reflects this logical visual order. If you do this, assistive technology users, as well as keyboard-only users, will thank you.
Using properly authored, semantically correct markup, doesn’t automatically mean full compliance with web accessibility requirements (e.g. EN 301 549), but it’s the best place to start.
When it comes to rich internet applications (RIA) with non-standard web widgets (e.g. tabbed interface, menu bars) and dynamic content (e.g. alerts), then it is possible to surgically craft your HTML to ensure browsers understand your website’s functionality and content, so that they can, in turn, communicate this to assistive technology users. This surgery can be carried out with the use of Accessible Rich Internet Applications (ARIA) declarations. WAI-ARIA provides technical specifications, patterns and guidelines to make dynamic web content and advanced web interfaces more accessible to persons with disabilities. However, no ARIA is better than bad ARIA.
Keeping things simple will benefit everyone. For more information and resources related to digital accessibility, feel free to visit www.accessibility.com.mt/help.
Chris Porter is a senior lecturer with the Computer Information Systems Department within the Faculty of ICT, University of Malta.
Sound Bites
• Malta hosted the 18th conference of the European Association for Computational Linguistics between March 18 and 22. The EACL brings together researchers from all around the world working on the computational processing of human language. The conference attracted over 750 delegates in-person, and another 300 delegates online. A total of 449 papers were accepted in different tracks and published in Open Access through the ACL Anthology.
• Artificial intelligence language models are unable to link up similar words written in different scripts, which means that Arabic models cannot understand written Maltese. To solve this problem, a group of researchers, including from the University of Malta and New York University, Abu Dhabi, developed systems to transliterate Maltese into Arabic script and pass it through Arabic models which are much larger than Maltese models. Their results were presented at EACL2024.
For more soundbites, listen to Radio Mocha www.fb.com/RadioMochaMalta/.