In this course you will learn how to design and prototype user interfaces to address the users and tasks identified in user research. Through a series of lectures and exercises, you will learn and practice paper- and other low-fidelity prototyping techniques; you will learn and apply principles from graphic design, including design patterns; you will learn to write a design rationale; and you will learn how to design for specific populations and situations, including principles and practices of accessible design.
Universal Design: Physical Limitations
Loading...
From the course by University of Minnesota
Prototyping and Design
176 ratings
From the lesson
Universal Design, Accessibility, Special Populations
An introduction to universal design, with specific lectures focused on particular impairments, limitations, and populations.
Meet the Instructors
Loren TerveenProfessor
Computer Science and Engineering
Haiyi ZhuAssistant Professor
Computer Science and Engineering
Lana YaroshAssistant Professor
Computer Science and Engineering
Dr. Brent HechtAssistant Professor
Computer Science and Engineering
Joseph A KonstanDistinguished McKnight Professor and Distinguished University Teaching Professor
Computer Science and Engineering
Welcome back.
I'm here with Phil Kragnes as we continue through our tour of universal design for
making systems not only accessible for a variety of users with disabilities but
for overall better design and interaction.
And in this lecture we're going to look at physical limitations and
particularly designing to support motor impairments.
So when we talked about mobility impairments,we really
focused on a couple of categories.
General motor control,the issue that people maybe suffering from.
Trembles, the inability to do accurate pointing or
motor control of a device like a touchscreen finger,
or a mouse, or a trackpad.
And also motor limitations, limitations in reach.
General dexterity or two-handed coordination,
fatigue from excessive movement, all of which can create
challenges when we're dealing with interacting with interface.
Knowing this, we also talked a little bit about some
chronic disease conditions that might relate to some of these impairments,
because we've dealt with those in the context of the limitations
we're not going to bring that back up again.
We've already dealt with many of the things that come from that either under
the other lectures we've covered or will under motor impairments today.
So let's talk about some of the challenges faced and what we can do for
universal access.
Let's start with low pointing dexterity that's actually a fairly
substantial number of people that can't necessarily move
a mouse to be able to point to a small link or a small button on the screen.
What can we do to make sure that's not a problem as we're designing an interface?
>> Yeah, it really is amazing when you think about.
There's so many conditions from cerebral palsy to Parkinson's,
intentional tremor disorder, just plain nervousness, you know.
If you're up there in front of this crowd of 300 people giving a presentation and
by golly you can't get the next slide to load because that darn control is just
way too small.
And so by making controls a reasonable size,
you don't want to make a control a quarter the size of someone's fingertip [LAUGH].
Seems silly to mention but people do it.
And so operating that control whether it be
like touching it on the screen or by trying to target with a mouse,
the smaller the target the more difficult that is to do.
I mean that seems pretty logical.
We also want to make sure that control changes in
some way to let the person know yes, I am currently targeting this.
This may not apply obviously to a touch screen interface,
where you're going to just touch control.
You don't really have a mouse over type of thing.
But on a web design, you want to make sure that when you bounce over a button
maybe it becomes a pop up or push down and
that gives this person with this mobility impairment feedback that yes,
I've got the mouse pointer on that control now I can click.
We also want to make controls keyboard operable.
Maybe it's the person's coordination,
dexterity, reach, and movement of their upper extremities,
just prevents them from sliding this mouse around or rolling the track ball or
sliding their finger around on the track pad a bunch of times.
So we need to make sure those controls are keyboard operable so
we can tab through all the lanes, buttons, controls, widgets, and
other things on the page and then interact with those using spacebar to check or
uncheck a radio button or check box, arrow keys to move around.
And what's also important with that is showing keyboard focus.
I mean, you're a visual user and you got this mouse and
you put the mouse pointer over target.
Well you can see the mouse pointer is over the target and
in many cases the pointer itself changes.
You get this feedback but
when you're tabbing through a site, a page and
the keyboard the hover effect has been eliminated.
That person might have no idea what control their actually on,
so both the size of your target and feedback as to what target has focus and
when it has focus are really three key points for
addressing physical limitations.
>> I will say I've had a few applications I've used with these
tiny scroll bars, where I don't know exactly how or why they did it,
but they disabled keyboard-based scrolling.
You couldn't hit page down or arrow down to scroll.
And I started to feel a lot of empathy with the people who had to
deal with this all the time.
Fortunately, it's something I only use once a month and
I've started to learn that I just take my mouse,
put it somewhere and then lift it up so it doesn't move.
So I can click on the scroll down as if it were a button.
But I would probably be better off if it were actually a keyboard button
than if it were a mouse that was lifted off the screen.
Now it's not just about pointing though obviously, it's also about difficulty with
distant movements or just general slow input and fatigue.
And there's some things we can do to help users
who may be dealing with those challenges as well.
>> Yeah, you know we've mentioned the term proximity in
several of our previous modules.
When we're talking about people with visual impairment,
proximity doesn't mean that the correct label be read for control.
With people with learning disabilities and visual impairments, proximity
means that activating the control, that anything that happens as a result
needs to be in reasonable proximity in case the screen's magnifier enlarged.
Well, interaction with controls proximity is also important.
So we don't want to have a tab bar or
a tool bar across the screen at the top.
And when we activate one of those buttons all the controls relay that button.
Fall at the bottom of the screen or somewhere further down on the screen,
requiring a lot more movement.
And it doesn't matter whether you're someone with a mobility impairment
that maybe can't move quickly and accurately or you're a mouse user.
I just slid this mouse up here and
clicked on this button and now I've got to go from the keyboard back to the mouse and
drag it down the screen to get to the set of controls.
So we want to kind of cluster controls.
To make something appear, it should be in close proximity.
And this can go to keyboard navigation as well obviously.
If there are some buttons at the top and
they pop up a different set of controls further down on the page.
But yet there are intervening controls in between,
I've got to hit that tab key who knows how many times,
dozens of times possibly to get down to those related controls.
The other thing we want to avoid is two-handed or coordinated interaction.
So, I need to let’s say touch this control and this control.
Or I need to click on something and
hold the mouse key down while I press the space bar or
whatever combination you can imagine the key word there is combination.
Someone with dexterity issues may not be able to coordinate
their hands or even their fingers.
Or maybe the impairment is something like cerebral palsy, or just you know,
one of those darn things that many people encounter, their broken arm, or hand.
You don't want to be required to do one thing with one hand or
set of fingers while doing another.
That just introduces a level of complexity that's not good for
anyone under any condition.
>> Well and obviously, some of this is just not overriding
the accessibility features that the platforms already have.
Some of those are about turning
coordinated actions into sequential actions, which are really handy.
Some of them are about supporting alternative forms of input.
One other one that we've talked a bit about is timeouts.
Many of us may find it frustrating if we were trying to complete a transaction and
it gives us five minutes to complete it
which is not uncommon if you're doing something like buying tickets online.
Doesn't want the tickets to go back,
but five minutes sometimes seems like it's a stretch.
Just when you're trying to imagine how am I going to
figure out whether these tickets are what I want, and do I like them.
If you add limitations in input, you can run into some real serious challenges.
>> Yeah, again, someone who has trouble targeting, it may take them a little
longer to hold that pointer on control, and keep it on there while they perform
the actual click or actual touch a control on the screen.
So that dexterity issue speed and response,
moving down or somewhere else on the screen to touch a control
may take some users a significantly longer time.
We've already talked about keyboard navigation.
It's one thing to drag a mouse from
one upper left corner of the screen down to the middle or bottom right corner or
something that can be accomplished fairly quickly for the average user.
But if you're a keyboard navigator,
keyboard only Navigation, and you need to move from
a control in that upper left corner to a control along the bottom of the screen.
And there's several dozen controls in between.
It could take a significantly longer amount of time.
And so you get this time out and you're thrown back to another page.
Well, it already took you long enough to complete the page you were on or
the steps to get you where you were in the process.
And now you get to do it again and see if you can do it a little faster.
But because it's taking you this extra effort
to navigate the screen, you're starting to experience fatigue.
So timeouts, unless there's really some essential
reason to use them, they're best avoided for all users.
>> All right, so as we look at universal design benefits,
if we're designing well for users with motor impairments, one of the obvious
things that happens is that we all have targeting problems.
If we're in a moving situation, if you're sitting in a car or
if you're on an airplane during turbulence and so, we're going to end
up with better designs for use in motion just almost automatically.
But it also seems like we can deal with making people more robust and efficient.
So we've talked a little bit about just dealing with input device failure,
which I'm sure you've experienced,
as I have, that as long as you have devices, there's going to be failure.
And when you have battery operated devices, there's more frequent failure.
And knowing that you can finish that important thing from the keyboard, without
having to go change the battery, And deal with the time out can be awfully helpful.
But there's also, there's this strength of being a power user with keyboard
shortcuts that if you think about that as an accessibility
principle that you should be able to do everything from the keyboard.
It also turns into a power user design that, well, once you're doing that,
let's make it efficient to do it from the keyboard.
>> Yeah, I mean, it's a simple principle to understand.
Take your hand off the keyboard,
move it to another device, perform an action, move it back to the keyboard.
Well, you've got the time from keyboard to device, and device back to the keyboard.
That's time that could be saved by allowing keyboard
navigation, interaction and identification of keyboard focus.
>> Well and as all of you will see when we are talking about Fifth's law and
action analysis, keystroke level models, and the rest,
all of this can be modeled to show you what the potential savings are and
what the potential liabilities are as we go forward.
So with that we're going to wrap up our discussion of designing to support
motor impairments, universal design: physical limitations.
We'll see you back for the next lecture.
Explore our Catalog
Join for free and get personalized recommendations, updates and offers.
Coursera provides universal access to the world’s best education,
partnering with top universities and organizations to offer courses online.
© 2018 Coursera Inc. All rights reserved.
