Limit the number of links in the site bannerĪ lot of screen reader users get stuck trying to get through what feels like a million links before the main content of a page. If touch targets are too small, there is a big risk of the user missing them. Large touch targets are crucial for people who navigate on mobile devices using the touch method that we explained about earlier. So let’s start with some usability tips! Make touch targets large But only focusing on the technical aspects will not by default make your interface accessible to screen reader users. These ”softer” factors is something many people forget about. However, you also need to think about making it intuitive, usable and easy to navigate. Here’s a video showing how that can be used.Ĭreating screen reader accessible interfaces is a lot about coding correctly. But it usually takes a bit more time than the touch method.Ī super handy feature for people who know braille is the braille keyboard in iOS devices. Swiping is a more thorough way of navigating, since it sets the focus on every item, even on the smallest of click targets. I myself prefer using the touch method most of the time, but then I’ll switch to swipe navigation if I suspect I’m missing something on the screen. It’s very common for people to switch between these modes of navigation. Kind of like using the tab-key on a computer keyboard. Swipe navigation: Swiping left and right to move to the next or previous item.Touch navigation: dragging our finger across the screen, and getting what’s under our finger read to us.Instead, we navigate by moving our finger on the screen in one of two ways: Mobile screen readersĮven though it’s possible, most screen reader users don’t connect a keyboard to their mobile devices. Here is a list of around 100 shortcuts for the JAWS screen reader. There are many keyboard shortcuts for screen readers that lets you do everything from searching content to identifying the font of the text you currently are reading. For instance by pressing the h-key in JAWS – one of the most used desktop screen readers. Thanks to the awesome Screen Reader User Survey mentioned above, we know that most desktop screen reader users navigate between headings when they arrive at a new page. Either stepping from object to object or by jumping between different types of components, like headings, forms, links or landmarks. On a desktop, users will usually navigate using their keyboard. But below is a summary of how desktop and mobile screen readers are used. On smaller devices I’ll rely more on the screen reader and on larger devices more on screen magnification.Ī great resource to understand screen reader users better is the Screen Reader User Survey by WebAIM, which over a thousand people respond to about once every other year. The survey goes through things like:Īnd much more! So head on over to that site and learn all you need to know. Then I’ll turn on the screen reader when reading longer texts. For instance, I’ll sometimes rely on my sight for general navigation using a screen magnifier. So we often use a screen reader in combination with sight. One thing that most people I meet haven’t thought about is that many screen reader users, like myself, have some remaining vision. Software development at 450 words per minute How are screen readers used? You should check out Tuukkas own article on this topic, where you’ll also find a longer audio clip of the screen reader speaking at lightning speed: Pretty awesome huh! For reference, most sighted people read at about 150 words per minute, so he’s able to read at 3 times that speed. Here’s a 5 second audio clip of what that sounds like: The Finnish developer Tuukka Ojala has his set at 450 words per minute. The first thing most people comment on when meeting a screen reader user is the speed at which the synthetic voice speaks. So scroll down and check them out if you’d like! Fasten your seatbelt – they are quick! At the end of this article, we’ve added a few more videos with screen reader users, showcasing different screen readers on different devices.
0 kommentar(er)
