Menu
I have a webpage that includes a <textarea> that uses JavaScript in order to utilize keyboard inputs like the tab key in order to indent lines, etc, just like a normal word processor or text editor.
When ensuring my webpage is accessible for screen readers, how does one handle the tab key in this situation? The user can tab around the webpage just fine but when they tab into the textarea they cannot tab out of it because the tab key is being used in the textarea for a different purpose.
What is the best solution to ensure that screen readers don't have an issue with this?
383
If the keyCode is 9 (which is the key code for the tab key), we preventDefault() — this means preventing the browser's default behavior, which is usually leaving the textarea to go to the next element. Now, we use setRangeText() , which allows us to manipulate text in the textarea.
Using aria-modal="true" replaces the need to add aria-hidden="true" for elements that should be hidden from screen readers and not receive keyboard focus outside the modal while the modal is open.
There is no set standard for JavaScript code indentation. 4 spaces seems to be popular. Avoid using Tabs because Tabs may cause erratic behavior.
tabindex="0" means that the element should be focusable in sequential keyboard navigation, after any positive tabindex values and its order is defined by the document's source order.
Great question and thanks for considering accessibility. This problem is not only for screen reader users but others that have mobility problems and can't use a mouse and rely solely on the keyboard for input.
The issue you're trying to prevent is WCAG 2.1.2 No Keyboard Trap.
Using the tab key to allow indentation of text is a natural thing to provide for textareas. One way around the problem is to allow esc to get you out of "edit mode" so that the tab key can now naturally move the focus to the next object.
I'm guessing you have a keyboard event handler that calls preventDefault() for tab. If the user presses esc, change the way you're handling tab by letting it bubble up naturally (ie, don't call preventDefault()). To go back into "edit mode", the user can press enter or they can tab off the textarea then tab back to it (ie, go into "edit mode" onfocus).
One key point of WCAG 2.1.2 is
if [tabbing off the object] requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.
So if you use esc, you'll need some onscreen directions that tells the user to press esc then tab to move the focus off the object, and those directions should be associated with the <textarea> via aria-describedby so that screen readers know about it.
<div id="foo">Press ESC then TAB to move the focus off the field</div>
<label for="stuff">Enter your info here</label>
<textarea id="stuff" aria-describedby="foo"></textarea>
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
