Hello. My name is Alejandro Rodríguez Ascaso.
I am a lecturer at the Department of Artificial Intelligence at UNED.
This is the second video in the series
about the development of user requirements,
and it deals with accessibility and usability needs.
Specifically, today we are going to work through an example,
an example applied to a task.
A task consisting of the use of a voice recogniser to edit text,
to precisely improve usability and accessibility.
The profile we are going to address
is that of a user with little manual dexterity,
and the use case is that of editing text;
and within that use case,
one step in the basic course of action, namely dictating a paragraph.
Let us recall the interaction sequence.
In it, the first thing is to perceive the existence and position of controls.
Then, to perceive the status of those system controls.
Then, to activate the system controls.
Then, to perceive the feedback associated with that activation.
And the cycle begins again,
without forgetting that the user must be able to understand
both the output produced by the system
and, in general, how to use that product or system.
Let’s begin with perceiving the existence and position of controls.
We are in a voice-recognition system.
Therefore, it does not make sense
to expect to perceive the controls visually
or learn from the system how those controls are arranged.
Rather, the user needs to know which voice commands
can be spoken at each moment.
If we look up the Dragon user manual online,
we can see that there is a command called "What can I say?"
which opens Dragon's sidebar,
where the commands the user may use at that moment are shown.
We can now start to fill in our table.
First, we indicate the need we are identifying,
in this case, accessibility principle ACC-3-8:
information that describes the arrangement
of the parts of the system that enable its operation.
According to the user manual, this can be accessed
through the "What can I say?" command,
which allows the list of voice commands
that the user can enunciate at that moment
to be shown visually.
This same principle also satisfies recognition
rather than recall
according to Nielsen's usability heuristics,
so we also write that down in the table.
Next, after perceiving the existence and position of controls,
comes perceiving the status of those controls.
When Claudia is dictating text to her computer,
we see that at all times there is an icon, a symbol,
indicating to Claudia that the voice-recognition system
is ready to listen and transcribe her voice into text.
Indeed, accessibility principle ACC-4-5
states that there should be a visual indicator
that is visible to someone with visual impairment.
Is it visible to someone with visual impairment?
That is not certain.
Our recommendation would be to increase its size so that any user,
regardless of their visual ability, can perceive it.
For example, if I take off my glasses right now,
I am unable to see what is currently on the screen.
So we must ensure that visually presented information
is adequate for any user,
or at least for the greatest number of users possible.
For this reason, in this case,
the characteristic we want when preparing the user requirements
is that we would like to increase the size.
What are the implications?
Well, increasing the size of the indicator
might make it interfere with the rest of the visual information
displayed by the word processor.
At this stage of user-centred design, we simply note this implication,
and later, the engineering team working to improve
the accessibility and usability of this system will examine it.
Another principle applicable in this case is that controls and indicators
must be perceptible without needing to perceive colour differences.
In this case, colour does not encode any information.
We continue with needs related to visual perception,
in this case, adequate brightness in the information presented.
The desired characteristic is that sufficient brightness exists,
and usually, the brightness of a computer screen
is controlled by the user.
It will be necessary to check that the option to control brightness
in the operating system is accessible to the user.
Although this is not the subject of the design of our system,
but rather the design of the operating system
or the computer itself.
Next comes another type of need related to the perception of visual information.
In this case, information within the visual field
of people who are of short stature or seated in a wheelchair.
The desired characteristic
is that the user is in the appropriate position.
We note, as an explanation, that this must be ensured,
although again, this is not a characteristic
that affects the design or improvement
of our voice-recognition system.
Similarly, in the case of avoiding reflections or glare,
when perceiving visual information in the foreground
while there is a background,
it is the task of those who design Dragon NaturallySpeaking.
What we can do at this stage is state that contrast must be sufficient,
and note as an implication that there are tools
to check whether the contrast is sufficient.
For example, tools such as WCAG contrast checkers
can verify whether an application's contrast
complies with Web Content Accessibility Guidelines.
Let's continue with our sequence.
After perceiving the status of controls comes the activation of controls.
In this case, the characteristic we want is that the user,
who has little manual dexterity and not much movement precision,
can use the system.
Well, that is precisely why we have chosen this system.
Claudia can use this product
because she can dictate the paragraph with her voice.
As an explanation, I note that it will be necessary to ensure
that the user is in an environment without sound interference.
Again, this is not something we need to address in the design
of a new version of our voice-recognition system,
but there is no problem in noting it.
After activating the control,
we want the corresponding perception of feedback.
In this case, feedback is provided by Microsoft Word,
writing in the document the sentence that Claudia has just pronounced,
and that acts as feedback.
What we need is for the visual feedback
to be evident for people with visual impairment.
We write this down.
The feedback, the text of the editor,
must be checked to ensure that its visual characteristics
can be controlled by the user.
Again, this is not a specific task of the voice recogniser
but of the application that the recogniser is controlling.
Then, after perceiving the feedback,
the perception of the existence and position of controls begins again.
What does the user do? She says, "Start new line."
Here we are in another use case, we've called it "Start new line",
and in that use case, practically all the user requirements
are the same as the ones we have already created.
We see one small difference: in the feedback of the operation,
here the previous symbol no longer appears,
but instead the phrase associated with the command
that Claudia has just spoken appears: "Start new line."
That probably leads us to introduce some new principle
relating to the need to perceive feedback
associated with text in this specific case.
But let us not forget where we came from.
We have now completed our full sequence,
but we are still missing something very important:
comprehension,
understanding both the output of the system
and the functioning of the system.
Let us analyse all the needs step by step.
On the one hand, the usability principle help section and documentation
are satisfied because Claudia tells us at the beginning of the video
that there is user help that is useful and should be used.
On the other hand, the accessibility principle ACC-3-8
states that the information describes
the arrangement of the parts of the system
that allow its operation.
We saw that earlier.
There is also contextual help:
when the user says the command "What can I say?",
the list of voice commands that can be spoken at that moment
is shown visually.
We also saw earlier that this satisfied
Nielsen's heuristic principle of recognition rather than recall.
Let's continue with other principles related to comprehension,
for example, that text, symbols, etc., should be easy to understand.
In this case, the command texts seem appropriate.
It seems logical that when the user says "Start new line,"
it is a command that is quite easy to remember and understand,
precisely because the text corresponds directly
to what we want to do:
start a new line.
We do not like the symbol used to indicate
that voice recognition is ready to listen.
It is a symbol that does not necessarily need to be good.
It must be easily recognised by the user.
We might therefore want either to use a symbol
that is internationally recognised
as meaning that a voice-recognition system is active,
if such a symbol exists,
we do not know, we could look it up,
or to offer users the possibility of customising these contents.
The implication is that customising these contents
might increase the complexity of the user interface,
because it adds
another configuration question for the user.
This content that we have entered in the table
also applies to other principles,
for example, that products or services use standard conventions, words,
or symbols from the user's own culture;
that text materials are written as clearly and simply as possible,
and the usability principle of match between the system and the real world.
There is also another principle
relating to the comprehension of the information
displayed by the system:
that text, illustration, and diagrams have a narrated format.
This would improve comprehension for some types of users.
But as an implication, we must note
that generating audio information
might interfere with voice-dictation interaction,
because the voice recogniser might pick up that audio information,
or even if the user listens with headphones,
they may have difficulty generating voice commands
while simultaneously listening
to that audio information produced by the system.
To conclude, we can say that we have created
user requirements for usability and accessibility,
covering the following steps of the sequence:
perceive, activate, and understand.
But we are still missing some:
equivalent safety and privacy requirements,
avoiding personal risks, using the product efficiently,
using assistive products, and other cross-cutting issues.
See you in the next video.