2. Accessible Websites and Apps

Back to introduction

2.1. The Minimum Standard

All websites and apps of statutory bodies are required to conform at least to the EU Standard EN 301 549 of the Accessible ICT Procurement Toolkit, which includes the W3C’s Web Content Accessibility Guidelines (WCAG) 2.1 AA.

Web Content Accessibility Guidelines

WCAG 2.1 Level AA Compliance

https://www.w3.org/TR/WCAG21/

Non-statutory bodies should also adopt this standard as a minimum, in order to make sure they are more accessible to screen-reading technology, and because they, too, will soon be bound by legal accessibility requirements.

This also means that where third party websites are used, for example, linked to, or used for surveys or forms, these also need to be fully accessible to screen-reader users. It is not good enough that websites and apps are merely technically accessible with the endurance of workarounds and much patience by the end user. Apps and websites need to be as user-friendly to screen-reader users as they are to everyone else. Anything else is discriminatory.

2.2. Accessible By Default

Accessibility of an app or website should never depend on a person having to alter their default settings to accommodate the developer. Apps and websites need to be immediately accessible without any workarounds, in other words, as close as possible to the concept of ‘box-ready’.

2.3. Accessing Online Accounts

Accessing personal or collective accounts should be as simple and as intuitive as possible, with intuitive and accessible interfaces.

arrangement of icons headers and text should be readable and instructive where necessary, not omitting important instruction – i.e., everything needs to be readable by a screen-reader. All features should be well presented to highest web standards.

2.3.1. User IDs and Passwords

While private security is crucial, there needs to be a balance struck that respects privacy and security needs, but which does not prevent people from gaining access to their own personal data or to a service.

the provision or inputting of a new user ID or password should be made easily accessible. Where relevant, apps or websites should have tabbed boxes which have labels for user name and password in the correct order, and which work with all screen-readers.

However, even with high standards of accessibility, visually impaired people may still have difficulties in easily accessing their User IDs and passwords, and may still feel intimidated by the obstacles intrinsic to such security measures, especially since many may have limited or no IT skills.

For this reason, workarounds should always be available, i.e., alternatives to remotely accessing one’s personal data or account online, such as allowing a service or information to be provided by phone, or in person, with the use of agreed passwords as appropriate.

Use of a phone alternative should not mean that a visually impaired customer is kept waiting while they access information about their own capital, or while they wish to avail of a financial service on the same basis as their sighted comparitor. Such transactions by phone (presuming that the account number and selected digits from a user ID or password have been provided), should be as easy to use as possible.

2.3.2. Kaptchkas

Kaptchkas are intrinsically problematic for visually impaired people, whether the kaptchkas are visual or audio. Username and password should be used instead, with a four-digit verification clearance sent to the contact phone or email where a password has been forgotten.

[to replace final paragraph of 3.2 with]
Alt text has a limit of sixty characters, and as such is often insufficient in terms of giving enough detail in the description. In HTML 5, where descriptions exceed 60 characters, all images, including graphs, charts, pictures, logos, etc., should have an option of an in-page link for a detailed description of each image, including all relevant details.

< 1. Principles   3. Electronic Documents >

Back to introduction