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

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

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 screenreader 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 screenreader-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 screenreader. 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 screenreaders.

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.

2.3.3. Time-Limits

While time-limits for provision of access codes etc., is understandable from a security perspective, they can pose an insurmountable barrier to a visually impaired service-user trying to access their own details.

2.4. Useful Tips

A useful resource for creating accessible websites is to be found at:


Other useful tips include:

i). Documents

As mentioned in more detail in 3.3 of the next section,the most screenreader-accessible document format is Microsoft Word, and in the event that there are any documents that can be opened from the webpage, the webmaster should point the word documents activation towards ms word on the website user’s browsing device.

ii). Links

Key information, such as links, should not be embedded in images. Hyperlinking or embedding of links in text is fine, but whether the full link is given or the link is embedded in text, the title or subject of the link, as well as its location (e.g., the Health Service Executive), should be made clear before the link can be activated.

While many designers use the hyperlink design feature jointly with bookmarks to ensure the location of focus when a page refreshes, it is important that independent links on a page have their properties correctly set to be in logical order, activatable by both mouse, enter key and spacebar, since activation options differ on different devices.

iii). Logical Order

A screen-reader user cannot escape the order of items and elements as set in the web-design, unlike a sighted reader, for example, who can look at anywhere on a screen at any time, and interact accordingly. All websites etc., should have their contents logically arranged in their displays so that information is not disorganised and nonsensical when navigating using screenreading technology.

We have experienced a number of mistakes made by unknowing web designers who build websites by using the mouse to drag and drop elements on to the new website webpage, which means that there is no order for navigation. Because of this, one has to read the webpage while trying to make sense of elements that are not in order. But, worst of all, building with a mouse only creates annoying captions which say, “Click here”, which many of us find don’t work immediately, since they are mouse-activated rather than activated by keyboard commands. This inevitably greatly limits functionality.

iv). Communications by Users through the Website

While in-page email messaging, comment boxes, etc., should always be accessible to screenreading technology, a corresponding email address should be available alongside it just in case it is not accessible, and because it allows the sender to retain a durable copy of the communication they send.

v). Testing

  • Another big mistake made by web designers is not testing the website correctly. The best way to test the website, in terms of screenreader usability, would be to:
  • Do initial tests using the native screenreader on your device (e.g., Narrator (Windows), or Voiceover (Apple), etc.).
  • text with third party screenreading software: e.g., download NVDA, an open-source screenreader, at https://www.nvaccess.org
    And JAWS (limited version):
  • Unplug the mouse so that it cannot be used, and so that navigation and commands can only be done through the keyboard (for example, that the arrows and tab keys need to be used to navigate, and that the enter key or spacebar need to be pressed to activate such elements as menu expansion, links, etc). Many designers, when checking for accessibility, start off with good intentions, using keyboard command. However, they are so used to using the mouse, that they often revert to mouse-use without thinking.

It is important that the website is accessible on all platforms, such as Apple (iOS), Google (Android), and Microsoft (Windows), so that it can be accessed from a multiplicity of devices, including smartphones and computers. A website should also be tested so that it is compatible with browsers including Safari, Chrome, Edge, Mozilla etc.

< 1. Principles   3. Electronic Documents >

Back to introduction