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 clientside 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
If you need to organise your content under different headings, then use
down to
. If you want to display a list of items, use the native list elements (
or ).
Tabular data? You got it, use a native
. 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.
The browser always creates an accessibility tree that is consumed by assistive technologies. Incorrect markup will result in a substandard accessibility tree.
