5.1. The Basics.
5.2. Basic Principles.
5.3. Accessing Online Accounts.
5.4. Useful Tips.
5.5. Testing.
5.1. The Basics.
5.1A. A Note on Screenreader Software.
5.1B. Minimum Standards.
5.1A. A Note on Screenreader Software.
Screenreading software allows an electronic device to read aloud the text and buttons etc., appearing on a screen, and allows the user to navigate the text and buttons by touchscreen audio feedback, or by use of keyboard commands. All this means that screenreading technology allows a user to use a computer, read texts, and browse online, without being required to read the text on the screen, or even without having to look at the screen.
Computers, tablets and smartphones generally come with pre-installed, native screenreading software embedded in the device, and such software merely needs to be activated. These include Narrator on Windows and Voiceover on Apple, respectively. Furthermore, non-native screenreading software is available online or by downloading apps, e.g., free OpenSource software, NVDA (nvaccess.org), or the purchaseable software (JAWS), to mention two of the most commonly used.
Some ways of designing websites or apps override the default accessibility of templates for operating systems, and this often means that such apps or websites are inaccessible to people who depend on screenreading technology. Such creations are an example of disability by design, since – albeit unwittingly – through such lack of understanding, a web designer excludes such people from being able to use a particular website.
Before looking at the minimum standards for web design, it is worth noting first that in order to adequately navigate a website, a screenreader user will necessarily need to have their own screenreader software (of their own choice and experience), such as those already mentioned, running on their own system. Were this not the case, they would have no way of even locating the browser itself, nor would they have any way of finding the website.
Therefore, adding a screenreading button to a webpage is literally of no use to screenreader-users (i.e., people who already depend on, and are therefore already running, screenreading software on their device. Such people will not want to click a button to have two voices reading the web content at different speeds; and indeed, they are certain to prefer the one they have already running, with their own preferences and settings, and with keyboard commands or touchscreen gestures which they are already familiar with. Indeed, on-site screenreading facilities have little or no navigation capability, and the reader has no choice but to listen to every single word on the page, including to in-site links etc., and unless they can see and read the content with their eyes, they have no way of knowing where precisely to click to go to any links provided, without using their own screenreading software in the first place.
In short, making websites accessible means making them accessible to the screenreading software we are already using on our own devices; and it does not mean that a webmaster or public body pays for or creates screenreading software on their own end, to be on offer to, or activated by, visitors to the website.
5.1B. Minimum Standards.
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.
All websites and apps of public 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.
WCAG 2.1 AA 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 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.
5.2. Basic Principles.
5.2A. Accessible By Default.
5.2B. Logical Order.
5.2C. Images and Graphics.
5.2D. Communications by Users through the Website.
5.2E. Language.
5.2F. Compatibility with Alternative Colour Schemes.
5.2A. 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, they should be as close as possible to the concept of ‘box-ready’.
5.2B. 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 or disordered when being read or being navigated using screenreading technology.
VVI members 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.
Another basic accessibility issue experienced by us is where the navigation of a screen (on app or website) is divided by the developer into two discrete parts (for example, upper and lower half of the screen). Screenreader users (unlike sighted users) cannot see that there is more information in the other half, and the screenreader will not jump over to the second navigation field unless instructed to do so by the user (who does not know that this needs to be done).
5.2C. Images and Graphics.
Use of images or graphics for decorative effect may interfere with the accessibility of interfaces or material to screenreader users.
Where images are used, necessary information should not be confined to an image, but should be contained in the text itself, with the image merely used as an illustration to the sighted reader. In other words, images should be supportive of the text rather than vice versa.
Nonetheless, the descriptions of images themselves need to put the screenreader user at as little disadvantage as possible in terms of the information being provided in that image. Where maps are used, details such as dimensions, distances, and directions should be provided in the image description, as relevant, but with the information being provided as clearly and in as much detail as possible in the text itself.
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.
5.2D. 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.
5.2E. Language.
Each interface should be monolingual, except, where relevant, for links for versions of a website or app in other languages. Loan-words, such as the Irish loan-word Oireachtas in https://www.oireachtas.ie, is fine.
5.2F. Compatibility with Alternative Colour Schemes.
Operating systems have built-in features for alternative colour-schemes or themes, and some of these can be particularly useful, and are even intended for, visually impaired users. In Windows, for example, “contrast” settings can be altered; and in Apple, “invert Colours” is an option. When used by visually impaired people, these features are often the default type, so for example, A Windows-user may use High Contrast #2, and need to have every website and app compatible with that colour theme.
As such, websites and Apps should be configured so that they are compatible with, at least, “invert Colours” (Apple), and “High Contrast” (Windows).
5.3. Accessing Online Accounts
5.3A. General Guide.
5.3B. User IDs and Passwords
5.3C. Kaptchkas
5.3D. Time-Limits
5.3A. General Guide.
Accessing personal or shared 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, not omitting important instruction – i.e., everything needs to be readable by a screenreader. All features should be well presented to highest web standards.
5.3B. 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.
5.3C. 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. However, since many visually impaired people still do not have a phone, a contact number, for practical/useful assistance should also be present next to the kaptchkas.
Preclearance is possible while using some operating systems (such as IOS 16 and higher), and service-providers should support this feature where possible. However, until all screen-reader users use operating systems that have this feature, other alternatives should be arranged.
5.3D. 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.
5.4. Useful Tips
5.4A. documents.
5.4B. Links.
5.4C. A Useful Resource.
5.4A. documents.
As mentioned in more detail in 6.3 of the next section, the most screenreader-accessible document format is Microsoft Word or Rich Text Format, 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.
5.4B. 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.
5.4C. A Useful Resource.
A useful resource for creating accessible websites is to be found at
https://webaccess.berkeley.edu/resources/tips/web-accessibility
5.5. 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 useability, would be to:
- conduct 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): https://support.freedomscientific.com/Downloads/OfflineInstallers#jaws - 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.