Hearing is Believing Part 2 - How - Screen Readers...

Jocelyn_Dart · ‎02-16-2016

Understand the basics of why and how to provide Screen Reader capability for Fiori, SAPUI5, or OPENUI5 apps.

In Part 1 I discussed WHY application developers should provide for Screen Readers. In part 2 I show the basics of HOW providing for Screen Readers works in Fiori, SAPUI5, and OPENUI5.

This blog will show a couple of examples … more detailed examples to follow in a later post (check in with the SAP Fiori - Accessibility collaboration document from time to time if you are looking for that). You'll see why soon...

Image courtesy of imagerymagestic at freedigitalphotos.net

Label (almost) everything ... revisited

Ok so in part 1 along with discussing WHY you should provide for Screen Readers, I also introduced the basic concept of HOW: Label (almost) everything.

So at this point let's clarify the difference between approaching Screen Reader provisions as an application developer and as a controls/framework developer - because some of you out there are both. While I won't dwell too much on the controls side in this blog, it's helpful for application developers to understand what the controls developer provides.

If you are a controls developer consider this a first introduction into conceptually what you need to do. Because when it comes to Fiori and Accessibility - good controls developers ROCK! They make the job of the designer and application developer easy.

As a controls developer you decide which:

ARIA Role is assigned to your control
ARIA States are set as your control changes state
ARIA Attributes are relevant to your control
Make sure the Properties and Associations of your control and mapped to the relevant ARIA attributes

I'll leave it there for now as this is obviously a big topic worthy of it's own blog, maybe even it's own blog series. If you need more in the meantime, make sure you read the SAPUI5 SDK section SAPUI5: UI Development Toolkit for HTML > Developing Content > Developing SAPUI5 Controls > Accessibility Aspects for SAPUI5 > Screen Reader Support for SAPUI5 Controls. I also recommend our own Stefan Schnabel's Accessible Rich Internet Applications (ARIA) - Part 2: ARIA as a deeper introduction.

Personally I'm very grateful to the controls developers, because the work they do means that as an application developer, I don't need to worry about the ARIA role or state or structure. All I need to do for each control is:

Check the available and properties and associations
Make sure I have an end user meaningful label
Associate the label correctly to the control

In fact if the controls developer is really clever, I may not have to do anything at all - no DO NOT STOP READING! While the author of the SAPUI5 SimpleForm control is now on my Christmas Card list, that's still the exception rather than the rule.

What about the (almost)? As mentioned in Hearing is Believing Part 1 - Why - Screen Readers, Accessibility & Fiori...where controls are purely for decoration you don't want to annoy Screen Reader users with a "sorry you can' t see our glorious background image" message. Instead you want the Screen Reader to ignore those. I'll explain how a little later.

Providing for Screen Readers needs Designers as well as Developers

When it comes to the content of labels there is one consideration that overrides all others – is the label meaningful to the end user. Making sure the label is truly meaningful is the job of the designer.

If the end user doesn’t know what the label means you may as well have written it in Sanskrit. Poor labels:

Reduce productivity – the user has to slow down to figure out what it means
Reduce accuracy – the user may misinterpret what it means
Increase training costs – you have to teach the user what it means
Increase support costs – you need to remind the user what it means

So someone needs to take responsibility for ensuring the labels are meaningful to the end user. In practice this is usually one of the responsibilities of the UX designer. While the developer enters the label, and the business expert identifies the correct term, it is often only the designer who has the perspective needed to choose a name that is meaningful to end users.

Let’s face it – most developers - and I include myself here - are not great at naming things. Let alone choosing meaningful names. Which is one of the many reasons why most sites have naming conventions for developers to follow. Don’t get me wrong – it’s not their fault. Good naming is just not part of their domain of knowledge. Which is why a label for an accounting period start date may end up as:

ZACPERSTDT or Ac.Per.St.Date

And the panel which surrounds it may end up with the ever enlightening (not): Group 1

In my experience, many developers also have an unfortunate tendency to view labels as decorative, because they don’t impact the function of the app or business process. So they are not motivated to improve the text even when they know it's not meaningful.

Business experts have the domain knowledge to make good names, but may lack the end user understanding to make names that are meaningful to the end user. Which is why a label for an accounting period start date may end up as:

Acc. Per. Start Date or Accounting Period Start Date

And the panel which surrounds it may end up as: Accounting Key

That’s why you need UX designers to choose your labels. In making the label the designer brings together business domain knowledge, end user research, and the context. Then the designer watches how end users respond to the label, to validate that the label is interpreted correctly. Which is how you make sure that your label for an accounting period start date ends up as:

Start Date of Financial Month

(or better yet is derived from some other date that is even more meaningful – such as Date Invoice Received)

And the panel which surrounds it may end up as: Invoice Header Details

End user validation also checks that users have understood the label rapidly and without undue effort. While you may provide additional help information for newbies, you don’t want occasional users to have to look at the help or call support again and again. That just reduces productivity and increases frustrations.

Now we do have some rules around the content of labels - you have probably noticed that SAP delivered Fiori Apps use the same consistent word for the same thing. For instance: on a button Remove is used when the button clears the reference to an item, and Delete is used when the button deletes the item itself. SAP delivered apps also use English(US) spelling; and avoid abbreviations and contractions that can be hard for people with literacy issues. These are all part of SAP's design guidelines. You might have similar guidelines at your site, or just want to follow the patterns you see in our labels. Unfortunately SAP doesn't currently publish these (although by all means advocate for including these in the SAPUI5 SDK), but most are easy to observe. If you are looking for more ideas, then Apple publishes some tips for developers in their iOS Developer Library under the topic Crafting Useful Labels and Hints.

It is isn’t enough just to have a label. For the label to be effective it must also be meaningful.

How do I include this in my Fiori app

It’s actually reasonably simple - at least in concept.

Make sure you are developing on SAPUI5 (or OPENUI5) version 1.30 or higher
Make sure you are using accessible controls
For each visible screen control, provide a label that is properly associated with the element it describes.

There are a several different ways of providing a label. Depending on the element and UI5 control, you need to decide which attribute best suits the situation. Occasionally, you may even want to provide more than one label for the same control. Often it’s obvious which type of label to use, but sometimes it may take a little more thought.

But let's start with what you need from the SAPUI5 (or OPENUI5) framework...

Providing for screen readers first and foremost relies on use accessible controls. Specifically you need controls that provide Screen Reader support. Controls that provide Screen Reader support do so in a number of ways:

They set the appropriate ARIA role(s)
They set the appropriate ARIA state(s)
They provide options for setting ARIA attributes that are appropriate to the control - including labelling options

At this point it's worth remembering that in this blog we are only talking basics. So yes there are certainly other ARIA attributes that can be set.... but that's topic for a future blog. If you are curious you can find the list in the W3C ARIA specification.

Essentially it's the job of the controls developer to make it as easy as possible for the app developer to include Screen Reader support in their app. For example, if the control has an existing attribute that has the same intent as the ARIA attribute, then the controls developer will usually reuse the existing attribute, rather than create a new attribute.

That's one of the reasons it's taken until SAPUI5 version 1.30 to provide screen reader support. The good news here is that from 1.30 onwards there are quite a large number of controls that provide screen reader support. For those delivering the SAPUI5 framework it's a continuing journey as new controls are added with each SAPUI5 version and existing controls are improved.

That's also why, as a rule of thumb, you want to get to the highest SAPUI5 version you can to maximize the accessible controls available to you as an application developer.

As of version SAPUI5 1.32 this is the list of controls libraries that provide screen reader support. Make sure you check the current list for your SAPUI5 version. You can find the list in the SAPUI5 SDK under SAPUI5: UI Development Toolkit for HTML > Essentials > Accessibility Features > Screen Reader Suppor....

sap.m
sap.suite.ui.commons
sap.ui.commons
sap.ui.comp
sap.ui.core
sap.ui.generic
sap.ui.layout
sap.ui.suite
sap.ui.table
sap.ui.unified
sap.ui.ux3
sap.uxap
sap.viz

So what types of labels should you use in your app? That depends largely on the intent and purpose of the control. For starters if you there is already an existing label on the visual display for sighted users, you probably want to reuse the same label for Screen Reader support.

Here’s a summary of some of the most common types of label that are present in SAPUI5 controls. Remember that ultimately it's the controls developer who decides how the labelling fits with the control, so always check the properties and associations of the specific control that you are using in the Explored section of the SAPUI5 (or OPENUI5) SDK. And yes.. .for some controls you might want to use multiple labels.

Label Type	SAPUI5 Usage	Use When
labelFor	attribute	Associate a label with a single input control.
text	attribute	Some controls have an existing text attribute, and will use that as the label. This is especially true for radiobuttons and checkboxes where the label is an integral part of the control
ariaLabelledBy	attribute	Apply the same label to multiple related input elements. This is also a great way to associate any available label with your control, without having to worry about whether it has already been used for another control or not. Many - but not every - controls support ariaLabelledBy as an association. Make sure you check Explored!
ariaDescribedBy	attribute	Provide additional (more verbose) information, e.g. to read the currency when you focus on an amount field Many - but not every - controls support ariaDescribedBy as an association. Make sure you check Explored!
placeholder	attribute	Add a placeholder text that will be shown when an input element is empty. This gives the Screen Reader something better to say than "Blank" or "Empty"
alt	attribute (e.g. sap.m.Image)	Add a descriptive text to an image; or a tooltip to an icon
Title	control (sap.m)	Add a label to a complex control that contains other controls, such as a Page, Panel, Form, RadioButtonGroup, or even the title on your App itself
InvisibleText	control (sap.ui.core)	Add a label that is only available to the Screen Reader and will not appear on the visual display. This is a kind of "get out of jail free" option when you don't want to clutter up the visual display with a label that's not needed by sighted users. You can create an InvisibleText and use that as a label of another control. Often the easiest way to assign an InvisibleText to another control is to use the ariaLabelledBy attribute.

There's one more image attribute that's worth knowing now. Say you have a purely decorative image and you want the Screen Reader to ignore that, how do you do that? Easy. Use the sap.m.Image control and set the decorative attribute to true. But be careful - make sure that image isn't actually a link or a button or you might unintentionally turn off a useful feature!

Simple Example of Correct Labelling

Let’s look at a simple example using labelFor

Here we have a Fiori app with an input element for entering a First Name. Now I could code it this way by simply putting a sap.m.Label control followed by a sap.m.Input control and rely on the visual order:

This will look correct visually. But when I run it through a Screen Reader the label and the input element are treated as two separate elements. So if I focus on the label in the Screen Reader I will hear "First Name", but if I focus on the First Name input field, depending on the Screen Reader, all I might hear is "Blank" or "Unknown" or "Edit type in text". None of which are all that helpful.

Even if it contains the name "Harry" all I hear is "Harry" - is it the first name or the last name or the middle name or a product name? I have to move the cursor around to guess at the matching label - which could be to the left of the name or in a different column of a table or above the name. It might not be that easy to find when I can't see the screen.

What we need to do is associate the controls together. This means that whenever I focus on the input field I get all the information I need to know what I need to do. Usually to make the association, each control needs a unique id so we can identify it. For example, to make our first name input field accessible we could change the First Name label and input field like this:

Now whenever the cursor focus lands on the first name field it reads out the label and it's contents. So if the first name contains the text Harry, you would hear “First Name Harry” in NVDA and “First Name edit Harry type in text” in JAWS.

An example showing how to assign a label to a complex control using the sap.m.Title control and the ariaLabelledby attribute

In this example we have a simple radiobutton group. We use the Title control to add the "Select an option" label to the group.

<Title id="rbgTitle" text="Select an option"/>

</buttons>

</RadioButtonGroup>

And a final example assigning a label to a complex control using the sap.ui.core.InvisibleText control and the ariaLabelledby attribute

With a control like the radiobuttongroup example above, sometimes we don't want to show the "Select an option" on the visual display. We might think it's obvious on the visual display. Or we might just want to reduce the clutter on the visual display. In that case we could instead use a sap.ui.core.InvisibleText control. This will provide the "Select an option" text to the Screen Reader, but hide it from the visual display.

<core:InvisibleText id="rbgHiddenTitle" text="Select an option"/>

</buttons>

</RadioButtonGroup>

In summary: Make sure you use controls from control libraries that provide accessible controls. Make sure you associate appropriate label(s) with your control.

Checking your Labelling

Without question, the best way to check your labelling is to get hold of a Screen Reader yourself, and get familiar with using it.

If you don't have one already - and actually you probably do without knowing it - read Part 1 for some suggestions.

However even if you don't have a Screen Reader, a quick way to check if specific ARIA attributes were set is to use any raw HTML inspection tool to check what was generated by the SAPUI5 control. I quite like Google Inspect. Firefox has a similar Page Inspector, and you'll find similar debug tools with other browsers.

Pulling the HOW together

What does that mean for your Fiori/SAPUI5/OPENUI5 project?

Task your designers with selecting labels that are meaningful to the end user.

Understand that the cheapest and quickest time to add labels is when you are building your app. Because when you are building your app you are naturally aware of your control choices and their properties and associations.

In Fiori, SAPUI5, and OPENUI5, adding labels is conceptually simple:

Make sure you use controls from the accessibility verified libraries.
Make sure you associate appropriate label(s) with your control.
Decide which type of label is appropriate to the control you are using
Assign an end user meaningful label to your control by coding the appropriate attribute(s) or control(s)

So now it’s over to you. Give it a go with your next app. And keep a lookout for future blogs giving more examples of best practice for specific use cases.

Looking for more on accessibility? Check in with the SAP Fiori - Accessibility collaboration document.