When you create a product, you naturally want as many people as possible to use it. However, some people have to be enabled to use it first, namely by making the product accessible and barrier-free. This also applies to websites and applications that are implemented as part of software development.
UI designers, software architects, and software developers should be aware of accessibility requirements. A good UI designer knows what to look out for in order to make the user interface he designs accessible. On the user’s side, assistive technologies, such as screen reader programs, ensure a barrier-free display. A critical question would then be whether the development framework used also supports these measures.
Vaadin has done its homework here and provided a handy guide (https://vaadin.com/accessibility). This is based on American legislation (508 standard) and the standards recommended by the World Wide Web Consortium (W3C) (here and here) and explains how they can be implemented with Vaadin.
Here we Europeans must now place our own standards alongside these, to see whether the proposed measures cover each other. This is particularly important if we are developing for government agencies and other public bodies, where stricter regulations apply.
A quick word on the standards and regulations that are meant here: Firstly, the EU Directive 2016/2102 on the accessibility of websites and mobile applications for public bodies should be mentioned. The term “websites” also includes any front-end web interfaces of applications, such as can be created with Vaadin.
The European standard EN 301 549, for accessibility in information technology, follows. This is referred to by the German Barrier-free Information Technology Ordinance (BITV 2.0), a statutory ordinance on the Disability Equality Act (BGG).
§ 2a of BITV 2.0 explicitly names websites or web interfaces and their content, as are
mobile applications. § 3 of the BITV 2.0 requires that the interfaces mentioned and their content must be “perceptible, operable, understandable and robust”.
The content must comply with the standards of the Official Journal of the European Union, i.e. the aforementioned EU standard EN 301 549. This in turn refers to the standards of the W3C, the Web Content Accessibility Guidelines 2.1 (WCAG 2.1). As a result, we will be on the safe side when we follow these, not only in Germany, but also internationally.
Assistance Technologies
Vaadin supports assistance technologies, such as screen reader programs or special keyboards, including attributes for the ARIA standard. Reference is made to an older Wiki entry for their use.
Vaadin does not interfere with assistance technologies and supports their focus tracking.
Alternative texts for non-textual elements (WCAG 2.1, Section 1.1.1)
Any embedded medium, which conveys content such as images and diagrams, requires an equivalent description in text form. This can then be read out by text-to-speech software.
In a Vaadin application, this would apply to AbstractEmbedded objects, i.e. iFrames, images and any Flash animations. Also affected are buttons with images.
Possibilities are alternative texts, which are linked to the objects or texts on the page itself. The latter would be useful for complex graphics such as charts and graphs.
Alternative, descriptive texts would also be needed for audio content. Transcripts would also be possible here. With Vaadin you can use ALT texts or labels for this.
Equivalent Alternatives for Multimedia Content (WCAG 2.1, Section 1.2)
Videos require subtitles, while videos without sound require a synchronized description. These need to be implemented using the video plugins of your choice. Vaadin itself offers no implementation options for this.
Alternatives for Colors (WCAG 2.1 Sections 1.4.1 and 1.4.3)
The conveying of information by means of colors should also be possible without the colors themselves. It could be useful here that Vaadin offers various themes to choose from when the user logs in. As a developer, you could provide a special theme for color blind people. You should also think about enough contrasts when designing your themes.
The readability of documents
Documents should be legible even with the stylesheet disabled. This allows screen reader programs to read the content of the page.
Image Maps
Client-side image maps are a requirement for accessibility. Vaadin already uses client-side image maps as widgets, via the ImageMap addon.
Tables
Line and row headers must be uniquely identifiable. With Vaadin Grid this can be done using the <th> element.
Data and header cells should be associated by using markup, if the rows and row headers of the data table have two or more logical levels. With Vaadin Grid, the cells of data tables can be associated with the respective header, via the scope ID and the header attribute.
The Identifiability of Frames
Each frame of the web interface should have a title, which describes the purpose and content of the frame. In Vaadin, frames and iframes can be provided with an ALT text.
Flickering Page Elements (WCAG 2.1, Section 2.3)
Screen flickering with a frequency higher than 2 Hz and lower than 55 Hz should be avoided. Vaadin does not offer any flickering elements, but you should be careful not to display videos with this property.
Alternative text-based web interface
A web page with text only content must be deployed when there is no other way to make the regular web page’s content accessible. This page should match the original page in content and functionality. This case should very rarely occur with Vaadin, since a Vaadin web interface can usually be designed to be barrier-free. With JSP and static HTML pages, however, such websites can be implemented in Vaadin, if necessary.
The use of scripting languages
If content and UI elements are rendered using a scripting language, then the presented information should be described with text that is readable by screen readers. This is usually already possible with Vaadin, since the content and functionalities, provided in Vaadin with scripts, are accessible to screen readers.
The provision of plugins
While Vaadin itself does not use any plugins, developers can of course still design their websites in such a way that the installation of a plugin on the client side is necessary. Here it must be ensured that there is a link with which the plugin can be downloaded. The content rendered by a plugin is usually accessible to a screen reader.
Forms
Forms displayed on websites must be able to provide their description, fields and functionalities using assistance technology. In Vaadin, the <input>, <textarea> and <select> elements have descriptive labels.
Simplification of navigation
Repetitive menus and long lists of links make screen readers more difficult to use. Here the developer can create links, which are only visible to these. If the link is activated, the screen reader jumps to the specified component. Such invisible links can be created in Vaadin with the style name “v-assistive-device-only”. Of course, structuring your headings well also supports navigation in your web interface.
Timed Replies
Certain web interfaces, for example for online exams, contain timed answers. The user should be informed of these time windows, with the possibility of gaining more time. Vaadin components themselves do not require timed user input.
Conclusion
Creating an accessible web interface with Vaadin does not have to be rocket science. The framework offers various possibilities for this, including out-of-the-box tools. Nevertheless, there are a few things to consider, especially when developing for a government agency or other public body.
However, accessibility is also an issue for enterprise systems and should of course be taken into account for B2C systems. We can provide you with competent advice on all Vaadin topics, including accessibility issues.
Published on Java Code Geeks with permission by Daniel Hugelmann, partner at our JCG program. See the original article here: Web Accessibility with Vaadin Opinions expressed by Java Code Geeks contributors are their own. |
