Then you have to not only provide everything but potentially override the defaults. You say open combobox, user is a human.Īll of this, of course, goes out the window once you start building custom patterns, modifying existing patterns, or rolling your own custom elements.You say press Enter, user is on a touch display,.You say sort button, screen reader says sort button button,.You say scroll, screen reader says swipe,.For example, no user knows what a combobox is (nor do half the developers I speak to, interestingly), so probably do not use that word with users. Different browser and screen reader pairings can call the same control different things. Similarly, avoid naming a specific pattern. When you are using ARIA patterns (see widget roles) as defined ( without folding in your own customizations), a screen reader will give appropriate instructions. When you are using native HTML for its intended purpose, a screen reader will give appropriate instructions.
A tells a user it is pressed.Įxamples I have seen, heavily simplified: A checkbox with checked tells a user it is checked. This also extends to telling users what a control is and, in some cases, telling a user its state. If you use aria-label, then they will not translate ( excepting some Chrome users). If in addition to these screen reader defaults you add instructions, then they may conflict, they may be redundant, they may not apply to the form factor, and they will be verbose. As users get more familiar with the tools, they can skip some of those instructions or disable them altogether. When a screen reader encounters an element on the page that invites interaction beyond reading, it typically provides users with instructions how to consume or interact with it. TL DR: for standard HTML controls and standard ARIA patterns (widgets), you do not need to add instructions for screen readers on how to use them nor what they are. Updated February 16, 2022, originally posted Octo11 Comments Stop Giving Control Hints to Screen Readers
0 kommentar(er)
