Implementing accessibility – challenges and obstacles
While the W3C recommendations on accessibility (Web Content Accessibility Guidelines, WCAG 1.0) have been around since 2008, and assistive technology (screen readers etc.) even longer, 99% of all developers of widgets, plug-ins and components – especially of popular JS/CSS frameworks such as Bootstrap, jQuery (and their UI kits) and WebApps based on Angular, React or Vue – act as if the topic of digital accessibility doesn’t exist. This partially or completely excludes about 20% of users who used apps or websites based on these technologies. Unfortunately, this is the sad truth.
A look back.
HTML5/CSS3
With HTML5 (W3C: 1st draft 2008, recommendation 2014) structuring HTML tags such as <header>, <main>, <footer>, <aside>, <nav>, <article> and <section>, among others were introduced. The stated aim was for HTML code to become inherently more semantic, so that web pages in general could be better read and interpreted by machines.
When most browsers started to support these new HTML tags (and CSS attributes) in 2010/2011, the web community embraced them. Table layouts had meanwhile been replaced by complex DIV-based layouts but the nesting levels had become so unreadable from a code point of view (“DIV soup”) that these new tags were supposed to help bring more order and clarity to the code.
However, the new tags were used rather hesitantly, in particular because IE (still a widely used browser at the time) did not support them well. As a result, JavaScript had to be used for these browsers in order to guarantee full HTML5 support. This in turn helped jQuery to become so popular because only jQuery was able to help bridge the various browser incompatibilities with the latest JS versions. Because of the relatively unclear application rules for the structured HTML tags, it remains unclear to this day how e.g. <section>, <article> and <aside> should be used in layouting.
From a UX perspective, on the other hand, the introduction of CSS3 was a godsend, as changes in the state of buttons, widgets, form controls or entire layout sections – thanks to new CSS attributes such as “transition” and “animation” – could now be displayed much more easily with CSS instead of JS. These empowered…or compelled… web designers (as opposed to programmers) to deal with this issue more. Thus, in addition to user interface (UI) design, user experience (UX) design also became central in the front-end development of web apps.
Web Accessibility Initiative – Accessible Rich Internet Applications
WAI-ARIA is a technical specification published by the World Wide Web Consortium (W3C). It specifies how the accessibility of (dynamic interactive) web pages developed with Ajax, HTML, JavaScript and related technologies can be improved to make them more accessible to people with disabilities, especially blind users using screen readers.
The WAI gave its first recommendation on this matter very early on (May 1999) with WCAG 1.0 (Web Content Accessibility Guidelines), which wasn’t finally adopted until 2008. Version 2.2 is currently being worked on.
ARIA is a purely semantic extension for HTML, which does not change the layout of a web page. For this purpose, information on roles, properties and states is added via JS/AJAX in dynamic web applications. Instead of relying on using the right HTML tags for the right purpose, ARIA has defined a set of new HTML attributes that can be assigned to any HTML tags:
- roles (e.g. role=”navigation”, role=”tablist”)
- Meanings (e.g. aria-label, aria-required, aria-invalid)
- States/properties (e.g. aria-current, aria-selected)
Unfortunately, there was and still is an overlap of interpretive sovereignty between ARIA and semantic HTML, with all the consequences of “ambiguities” or “bad practices” that this entails. The result is unnecessary ARIA statements ending up in tags where they don’t belong, such as <nav role=”navigation”> or <aside role=”complementary”>. Internet forums/blogs are full of posts on the subject: “No ARIA is better than bad ARIA. This is one of the core rules of WAI ARIA.”
ECMAScript 2015
With ECMAScript 2015 or ES6 (6th Edition), a JavaScript standard was introduced that was supported by all modern browsers right from the start. This triggered a boom in JS-based frameworks for frontend development, from which Angular, React and VUE, among others, emerged. These largely shape the look and feel of today’s web applications and component-based software development, not least through the so-called UI Kits, which were and are developed specifically for these frameworks.
Put very generally, the more functionality, configurability and ease of use that are packed into a component today, the more likely it is that accessibility will be neglected in the process. Form controls like practical datepickers and multiselects are available by the hundreds, but only a few can be operated perfectly with the keyboard and only very few meet the minimum accessibility requirements.
A current overview
This was our experience with ITS Applications (ITS APPS) just the other day when we upgraded a JS-based application and wanted to ensure accessibility. Out of 30 datepickers tested, exactly one was accessible. None of the multiselects were usable from an accessibility perspective. As a result, we (ITS Applications and partners from “ADG/Access for All“) decided to develop an accessible multiselect ourselves. The first prototype will be presented in mid-March 2022.
Anyone who wants to develop modern frontend applications today can choose from a multitude of JS/UI frameworks and libraries. Interestingly, you can read that many of them are “… compatible with the WAI-ARIA guidelines for web accessibility.” If you take a closer look at them, e.g. one of their components such as the datepicker, the multiselect or modal windows, you quickly reach the end of the line. Customising is often very cumbersome and documentation is based on very simple examples. Or accessibility is purely wishful thinking.
Anyone embarking on a JS/UI framework thus not only has to deal with the implicit design philosophy and the associated code base, but also has to ensure whether and how components can be adapted if customers or users want design or functional adjustments – especially if they demand differentiation (to be different from others) and individualisation (adaptation to one’s own processes).
And last but not least: Accessibility must be ensured no matter what technology is used on the learning and information platforms. This is a central point in ETH Zurich’s programme “Barrier-free at ETH Zurich“, which was launched in 2020/21.
ITS Applications now has four years to achieve this goal.
Contact
- Luis Argüello WCMS and Mobile Applications, ITS APPS (author of the article)
- Christian Schär, Group Manager WCMS and Mobile Applications, (ITS APPS)
- Manu Heim, Project Manager Accessible Communication (ETH CC)
erstellt am
in News
