Understand the basics of why (Part 1) and how (Part 2) to provide Screen Reader capability for Fiori, SAPUI5, or OPENUI5 apps.
In this blog we'll look at the WHY of providing for Screen Readers in Fiori:
- Who benefits when you provide for Screen Readers apart from the obvious (hint: it’s probably you)
- A high level overview of how Screen Readers work
- An appreciation for some of the challenges
In Part 2 I'll explain the basics of HOW to provide for Screen Readers in your Fiori, SAPUI5 or OPENUI5 app with a couple of examples.
Image courtesy of stockimages at freedigitalphotos.net
One of the reasons I find accessibility so fascinating is because it expands your mind as to how people work with digital technology. On project we find most developers remember their first contact with a Screen Reader. I certainly remember my first experience of a blind person using a Screen Reader over 5 years ago. It was a revelation.
In came this lovely senior gentleman with a guide dog. His name was Andrew. He was very polite, very patient, and very obviously blind. After introductions and confirming the plans for the day, he sat down in front of the desktop. We had loaded the JAWS Screen Reader software and the web page he needed to test. He checked the JAWS configuration. Then the real test started. And to me it sounded something like this…
“Bidddlierbiddierbildierblih… that’s all folks”
Porky the pig – legendary cartoon character
After the first shock of surprise, I glanced sideways to see his reaction. It seemed to make perfect sense to him. There was obviously some English in there. The Screen Reader was just reading it so fast I had no hope of understanding it. It was much like the first time you hear some people having a conversation in a foreign language. To me: it was gibberish. To Andrew: every word was clear.
I suddenly realised two things:
- The stories were true – when you lose one sense the other senses really do compensate. Andrew was clearly hearing words at a speed I had no hope of comprehending
- Assistive technology was cool – here was someone using text-to-speech technology daily at a time when for most of us it was still something you would only see in a toy or an arcade game
Then - the high cost of the few Screen Readers available on the market was a barrier to exploring this technology.
These days access to Screen Readers is easy and cheap. In fact you probably already have one yourself! There are Open Source solutions such as NVDA; and most major tablets and smartphones include some Screen Reader capability, such as Voiceover for iOS.
Despite the widespread availability of Screen Readers, there are still some challenges in providing for Screen Readers. But let's start with the basic concept of what you need to do to provide for Screen Readers, which is...
Label (almost) everything
As a Fiori, SAPUI5, or OPENUI5 application developer, providing for Screen Readers is first and foremost about labels. Now don’t get me wrong – there is a lot more to Screen Reader provision. And if you are creating your own custom SAPUI5 or OPENUI5 controls you will need to understand more. But this blog is focussed on the crucial basics. And that means the most important thing you need to do as an application developer is: Label (almost) everything.
Think of it this way: the job of a screen reader is to make the invisible audible. When you can’t see what’s on the screen, you need to hear what’s on the screen instead. That means every control that’s visible needs to be associated with a label.
Why the (almost)? If the control is purely decorative, then you want the screen reader to ignore it entirely rather than annoy the user with a “sorry you missed out on our glorious background picture” label.
Who Benefits from Screen Reader Provisions
Providing for Screen Readers benefits far more people and more devices than you might think.
Screen Readers are part of group of solutions known as text-to-speech (TTS) software. All text-to-speech software has a common requirement: they can only convert the text to speech if there is some available text that can be converted.
These days TTS software is readily available. It’s often paired with voice recognition software in solutions. TTS is an essential part of many IoT devices such as Amazon Echo. TTS is commonly available as an integral part of tablets and smartphones. And of course there are many commercially available, free and open source TTS solutions for desktops. TTS is also a critical part of solutions for healthcare, legal, and public safety contexts where the use of a keyboard, mouse or touch device can interfere with the work it supports. For instance, Dragon Naturally Speaking by Nuance, which was originally created to support legal dictation.
Think of it this way: When a surgeon is in the middle of an operation, they encounter something unexpected and need to check what your doctor observed, you want them to be able give a voice command and then listen to the notes from your doctor – not to have to pick up their tablet.
Text to Speech software including Screen Readers benefits:
- People who multi-task – having your device read the screen to you frees up your eyes and hands while you do something else. This is particularly true when the screen holds a large amount of text.
- People with different learning and comprehension preferences – some people find it easier to understand auditory information better than visual information.
- People with literacy difficulties - Many sites are only provided in English. If English is not your native language, but you use it occasionally for business purposes, you may speak it better than your read it.
Of course there are always those for whom Screen Readers in particular are essential:
- People with vision impairments - The more severe the vision impairment the more essential a screen reader will be to that person. People with partial vision may use a screen reader to supplement other assistive technology – as James Caston explained in Zoom Zoom or Why Size Matters - Accessibility & Fiori.
- People with learning disabilities such as Dyslexia or Dysgraphia - When visual information is not received in the brain the way it is intended, audio information can be a better alternative.
So just like many other accessibility features, providing for Screen Readers extends the reach of your Fiori, SAPUI5, or OPENUI5 app to many more people, and even devices, than you may have initially considered in your design.
How do Screen Readers work
Screen Readers are software solutions that interpret applications on a computer screen (apps, web sites, ebooks, folder hierarchies, etc.) to make the invisible audible.
Screen Readers produce synthesized speech - converting the text on the screen to speech. They also announce keystrokes entered on the keyboard. Most Screen Readers let you choose the simulated voice (male/female, accent) and adjust the speed at which the speech is read.
Many Screen Readers will also convert text and keystrokes to refreshable Braille devices attached to the device. Braille devices provide support for people who have auditory as well as vision impairments.
Some of the most popular and well known Screen Readers include:
- JAWS by Freedom Scientific
- ZoomText by Freedom Scientific
- WindowsEyes by AI Squared
- NVDA – NonVisualDesktopAccess – an Open Source solution
- iOS VoiceOver
- Google TalkBack – Android Text-to-Speech
- Microsoft Narrator
With so many choices which do SAP officially test against? JAWS – for the simple reason that for many years JAWS has had by far the largest market share and is therefore the most commonly used Screen Reader in the market. Unsurprisingly, along with the growing availability of more Screen Readers, that situation is gradually changing. But for now JAWS remains the most popular Screen Reader - as you can see in the latest WebAIM survey of screen reader users.
At a technical level, Screen Readers use an API built into each operating system. The API is designed to describe the roles, states, and structure of the user interface. How the roles, states, and structure are described typically uses the W3C international standard WAI-ARIA – usually known simply as ARIA.
ARIA provides a bridge between the DOM (domain object model) and the device (desktops, tablets, phones, and more). Browsers expose ARIA-enabled elements to the assistive technology API as if they were native widgets.
Without getting too technical about how ARIA works...
- Roles tell the screen reader whether it’s an editable field, a button, a link, etc.
- States tell the screen reader whether the field is able to be edited, whether the button is pressed, whether a link is disabled.
- Structure tells the screen reader how the information is organised – header, footer, banner, grid, list, table, etc.
If you are interested in a little more depth, you can find all the gory detail on the W3C Web Accessibility Initiative site. And our own Stefan Schnabel also gives an excellent intro to ARIA and the challenges of providing for HTML5 in Accessible Rich Internet Applications (ARIA) - Part 1: Introduction.
As an application developer ARIA is great news because it means we don’t need to include all that information in our labelling. All our labels need to do is focus on being end user meaningful (I'll come back to this in Part 2).
Note: The API is the other reason why SAP tests against one Screen Reader. Provided the information is available via the API to at least one Screen Reader, it must therefore be technically available to all Screen Readers. How a particular Screen Reader interprets that information is a matter for those who design and build that Screen Reader's software.
In theory the following ARIA standard and using assistive technology API provides the user with a consistent user experience, where dynamic JavaScript-driven widgets in app or web browser are comparable to their equivalents on the desktop. Later in this blog I’ll give you a little insight into some of the challenges that happen in practice.
Here’s the thing. The API gives the Screen Reader quite a lot of information, and the Screen Reader can pass that on to the end user. But the end user can only truly understand whats on the user interface and how to respond if that information includes a meaningful label:
- The end user meaningful label is available on the user interface
- The label is associated with the appropriate element
If there’s no label, the Screen Reader might know there is an input or actionable element but all it can say is “Blank” or “Unknown” or "Edit type in text" or it might even say nothing at all. If there’s a label but it’s not associated with the correct element then the reading order can become very strange.
Even worse, often there are grouping elements on the screen that have no text – such as panels, icon tab bars, radio button groups, et al. Without explaining the grouping the user interface may not make much sense. This is particularly true of forms which are often broken into logical blocks.
For instance if a form provides input fields for multiple addresses, it may become difficult to tell which address is for which purpose. Particularly when addresses are displayed side by side - in a typical left to right reading order you might hear something like "Sender Address, Receiver Address, Unit or House Number, Street, Unit or House Number, Street, City, City, Region or State, Region or State, Post code, Post code, Country, Country". So when the end user then tries to enter the Receiver Address and moves over and hears "Street", it's not fun trying to work out whether which Street was which.
Changes in background colour, dividing lines, and emphasized text are also often used to make visual sense of user interfaces. These are often not of much use to someone who can’t see the visual display, because many Screen Readers don't announce them. . Now some screen readers will announce colours, dividing lines, and emphasized text. But they may only announce them if they have been specifically configured to do so. So then to get all the relevant information your end user needs to already know that colours and dividers and emphasis are being used - before they have even used the app! That's not a very good experience!
As an application developer, labels are the most important way you provide for Screen Readers. Give the Screen Reader something to say, so that those who cannot perceive your screen visually, can understand it by using their other senses.
Don’t let the challenges of Screen Readers stop you
Screen Readers are one of the most challenging assistive technologies to provide for. However this is not a reason to hold off on providing for them.
Like most accessibility, the most inexpensive time to add Screen Reader provisions is when your app is being built. When your app is being built you are naturally aware of every control choice you are making and its consequences.
Retrofitting accessibility later is time-consuming and tedious. Even in the best case, each and every control needs to be evaluated and the appropriate remedial action decided - if that's "no action needed". In the worst case, controls chosen during build may need to be completely replaced. This may significantly change the user experience and if your user interface is already live this would typically results in increased training costs, increased support issues, and user confusion.
What makes providing for Screen Readers challenging? Two things:
- There are several layers of software that need to cooperate to produce the correct end result
- In most of these layers there is significant and growing - but currently inconsistent - support of ARIA
Say you want to use Fiori, SAPUI5, and OPENUI5 apps. You need to use a Screen Reader. This is a high level view of the software layers you will need:
- The bottom layer is the Device itself and its operating system.
- On top of this is the web browser which interprets HTML5, JavaScript, JQuery and CSS.
- On top of this to the SAPUI5 or OPENUI5 libraries that contain the controls for your app. These will generate the raw HTML5/JavaScript/JQuery/CSS for the browser to interpret.
- On top of the libraries, is your app itself. Your app specifies which UI5 controls to use and sets control attributes that will be used by the SAPUI5/OPENUI5 libraries. Your app may even override the behaviour of some controls or add custom controls.
Where does the Screen Reader software itself run? That depends on the device.
When running on desktop the Screen Reader is yet another layer of software that runs on top of everything else. When working with tablets and phones, the Screen Reader may itself be a part of the operating system.
First the good news. According to their documentation, usually all the software layers respect the WAI-ARIA standards.
Now the challenging part. These standards are comparatively new – they started in 2008. So unsurprisingly the standards are not applied consistently or completely in all layers. This is especially true of support on tablets and smartphones.
There are some helpful sites that track ARIA support against specific web browser versions and Screen Readers - such as canIuse - and you also find dedicated accessibility professionals who track and share information - such as WAI-ARIA Support Matrix.
So why you don’t want to hold off? Even though the WAI-ARIA standards are applied inconsistently right now, with each release upgrade of operating systems, web browsers, and yes even the SAPUI5 and OPENUI5 libraries, the support for WAI-ARIA is increasing. There is sufficient capability in most layers for the essentials to – usually – work.
If you hold off you risk:
- Facing high costs in remediating the app later
- Excluding all sorts of users who would benefit from even an imperfect rendering
- Costly legal and social responsibility consequences - a sampler of Accessibility Lawsuits in America
How can you best deal with the inconsistencies?
- Test your app's full functionality with the Screen Reader activated - don't just test the accessibility features. For instance don't just check the labels are ok - check every button, link, slider, etc. works as intended.
- Test your app against more than one web browser/Screen Reader combination. This is one of the quickest ways to resolve whether the problem is in your app, the SAPUI5/OPENUI5 control it uses, or the web browser or screen reader itself. I'll give some more tips in part 2 that will make more sense once you understand the "how" of providing for Screen Readers.
- Give users who rely on Screen Readers some degree of freedom in choosing which combination they use. As James Caston explained in Zoom Zoom or Why Size Matters - Accessibility & Fiori, it’s not uncommon for people with disabilities to need to use more than one assistive technology. Maximize their productivity by letting them choose what works best for them in each situation.
Pulling the WHY of Screen Readers together
Screen Reader provisions are helpful for many groups - and IoT devices - and essential for the severely vision impaired.
The most important way to provide for Screen Readers is to add meaningful labels that Screen Readers can use to make the invisible audible. Build Screen Reader provisions into your Fiori, SAPUI5, and OPENUI5 apps as you build them.
Be prepared for - but not discouraged by – inconsistencies you may encounter. Be a part of the movement towards more consistent WAI-ARIA support.
Now onto HOW in... Hearing is Believing Part 2 - How - Screen Readers, Accessibility & Fiori.
- SAP Managed Tags:
4 Comments
