Physical disabilities 101

Physical disabilities include any limitations of muscular control, any pain that has an impact on movement, missing limbs, and others. In some cases, physical disabilities can even be temporary. Those who have physical challenges may use a wide variety of tools to help them access websites and apps. These tools may include alternative input devices like switch systems, one-handed keyboards, or head mice. They may also include technologies like voice control and dictation. However, users of all of these access tools have several concerns in common. 

Web accessibility considerations

• Keyboard access: Many users with physical challenges lack the ability to use a mouse. It is extremely important for users of voice dictation, and other alternative input methods, that all controls on a website are keyboard accessible.
• Timing: It may take longer to complete tasks. It is important to ensure that if a session expires, or there are timing limitations, a user can restart, or continue, without losing any work they’ve done.
• Focus indication: It is important that the currently focused element is clearly indicated visually, in order to help users understand what control has the focus, and what they’re currently interacting with.
• Large focus targets: users who have difficulty with hand-eye coordination may have difficulty clicking on small targets, or hovering over small areas of a webpage. 
• Correctly labeled controls and alt-text: in order for a user of voice control to successfully activate a control, it is important that it has been given the correct label, and that this label matches what a voice control user would expect when visually looking at the webpage.
  

Picking the right tool for the job

It is rare that a user with a physical challenge will use one tool, and one tool only.  Instead, depending on the situation and task, users with physical challenges will mix and match tools to pick the best tool for the job.  For example, some users will use voice recognition to dictate text if they have difficulty using a keyboard, but will use a mouse to operate the interface elements of a website or app.  Others may use voice control for almost everything, but are still able to revert back to a mouse or keyboard when voice control isn’t working for them in a particular situation, even if the mouse or keyboard may be slower and more difficult for them. 

Things to keep in mind during meetings

• Account for extra time. Users with physical challenges may take longer than expected to complete tasks; make sure to allocate plenty of time for each task you would like to test during a meeting. 
• Expect programs to run slower than normal. Voice control software like Dragon NaturallySpeaking may run slower than expected during a Zoom meeting, as both programs are accessing the same microphone, and processing the input in different ways. 
• Be aware of system limitations. When a user of a virtual keyboard is sharing the screen via Zoom, the virtual on-screen keyboard, or other elements added to the screen by their assistive software, may not show up visually
• Be mindful of energy levels. Due to the nature of their physical challenges, many users may tire quickly.  When meeting with users with physical challenges, it is often better to plan for several shorter 30 minute meetings, than one extremely long meeting.

Things to keep in mind when writing user journeys  

• Keep user journeys short and simple. As it may take these users somewhat longer to perform tasks, it is a good idea to split journeys into several shorter journeys, rather than a single extremely long one, when possible.
• Confirm accessibility features in advance. If testing with users who use alternative input methods like voice recognition or switch systems, it may be a good idea to first verify that your website implements keyboard access, and that all elements and controls are labeled.  Doing this will help make your test as successful as possible, and help you gather the most useful feedback you can, rather than just having all of your testers fail at step 1.