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.
