Is it possible to make an element tabbable for screen readers only? I know that I can make an element non-tabbable for all devices (tabindex="-1"), but is there something like aria-tabindex? So I could do the following:
<input type="text" tabindex="-1" aria-tabindex="0" />
I need this because a client wants a fancy GUI for some normal HTML inputs, and so I'd like to make the inputs themselves non-tabbable (for visual users who can use the GUI), but make them tabbable for non-visual users (who then simply can act on the HTML inputs, and the GUI can be hidden with aria-hidden="true").
Update
I found a solution to my specific problem (provide a fancy GUI to visual keyboard and mouse users while not disturbing the experience of screen reader users) in this blog titled An accessible, keyboard friendly custom select menu:
The trick is that the native select element is placed above the fancy GUI (visually hidden using opacity: 0), which itself propagates the received clicks to a custom JS which manipulates the native select. This way the GUI doesn't need to be focusable, which solves my problem for this special case. Even text browsers will enjoy the full experience.
I don't know how far this trick can be extended to more complex fancy GUIs, but it's definitely a nice idea.
If you could do this, you would make the form unusable for sighted visitors who have mobility issues that prevent them from using a mouse. They rely on the keyboard in the same way that screen-reader software users do.
You could add keyboard support to the fancy GUI versions, with ARIA used to describe what each part does (ARIA can only describe things, it doesn't add or remove any functionality). I've also seen fancy inputs added as a progressive enhancement over the top of standard inputs, with the graphics just given an aria-hidden=true so they don't appear as duplicates to non-sighted users.
Edited to add: Filament Group has some styled form inputs in the accessible forms section of their code samples page. They're a good example of what I mean.
Related
We've implemented a content switcher using a native dropdown select element, which switches between HTML tables directly underneath. This is to be used inside blog posts, with various table content relevant to the post. The table will be switched out immediately using JavaScript upon selecting an option from the dropdown. Simplified code below for illustration. We're using React but I don't think that affects the question.
<div className={styles.csvList}>
<label for="csv-table-selector">{label}</label>
<Dropdown {...}/>
{selectedTable && (
<div id="selected-csv-table" role="region" aria-live="polite">
<h2>
{selectedTable.name}
<h2>
<Table {...}/>
</div>
)}
</div>
Right now we’re using a ‘polite’ aria live region containing the table, which will start to read the whole table out when the table changes. This is very similar to the Mozilla Docs implementation example for live regions.
Is there a limit for the amount of content which is sensible to keep in a live region? I couldn't find any resources anywhere online with guidance for when content is 'too much'. With tables, my assumption was that the screen reader user would prefer to navigate them manually rather than have the whole thing read out.
I also considered having a visually hidden live region, which will read out something like 'Table was updated below' when the table is changed. Is this more desirable than the whole table being in a live region?
Is this design doomed to be confusing for screen reader users? I'm aware that the 'tabs' design pattern is more usually used for this kind of scenario, so was wondering if we should abandon the dropdown switcher idea and go with that instead.
Yes, I would definitely recommend applying the Tabpanel Pattern as this will simplify work for you, and the users.
Because expectation is simply that when the active tab changes, the immediately following content changed. No additional announcement is necessary.
Solution with Dropdown, Without Live Region
If you still would like to use the dropdown, the expected behaviour would still be somewhat similar.
Instead of announcing that content change somewhere on the page, you would guide the user directly to the switched table by setting focus on it. Of course the table has an accessible name.
This way you wont ask the user to navigate themselves, after the announcement, but it’s already done.
TIL that screen reader users rarely use tabs for navigating web pages and instead use specific keyboard shortcuts from their screen reader software (e.g. CTRL + OPTION + Arrow Keys in VoiceOver). This would mean that optimizing for tabbable navigation does not always make sense.
However I've seen some web pages adding tabindex="-1" to their headline elements or for elements that are not directly viewable due to overflow: scroll.
So my question would be: When does it make sense to optimize for tab navigation and when doesn't it?
E.g. in our current use case we've created a questionnaire that basically shows a question (h2 element) that can be answered with 2-5 answers (button elements). Clicking the answer will lead to a new page with the next question. When activating VoiceOver it seems like a good idea to have the question element set to tabindex="-1" and auto-focussed when the question is opened. But the learning above seems to challenge this a bit.
Thanks for your help!
So first of all you are confusing tabbing with focus. While a screen reader user may use arrow key navigation, they may also bring up a list of links on the page, or forms, regions, tables or (most often) headings in order to navigate to sections that interest them / get a feel for the page layout.
Tabbing is useful as there are plenty of people who cannot, struggle or prefer not to use a mouse but do not require the assistance of a screen reader i.e. Cerebral Palsy due to accuracy issues.
Hopefully that clears that bit up for you.
As for autofocusing an input on a multi-page form, that is more of a UX issue...is it good UX for all users if you auto-focus the form.
I would say yes, requiring people to click, tab or use shortcuts to get to the input if that is going to be the action that 99% of people need to take is not good UX.
Notice I say the <input> and not the heading.
What you do want to do is look into how to indicate this is a multi-page and multi-step form on the first page of the process.
You should also consider having a checkbox as the first step that says something like "this form is multi-page, would you like us to auto-focus the first question when a new page is loaded" and have it default to checked.
That way someone has the choice to stop the auto focus if they wish.
Additionally (or as an alternative if you do not want the checkbox) you may consider adding some text near to the submit button (and properly associate it with aria-labelledby and an ID) that explains that the next step loads a new page and the first input will be auto focused.
Another thing is that assuming you have titled the pages correctly (Form name or process - step 2 of 5) then a screen reader user can easily ensure they are on the correct page.
So focus the input if this is a multi page form, not the heading level 1.
Focusing headings after navigation is a trick for Single Page Applications (SPAs) so that might be where you have seen that, if you load the page content via AJAX then that is one of the recommended ways to handle navigation. You indicated next page "loads" which makes me think this is a Multi Page Application, but I thought I better add that just in case as a general tip.
Bear in mind that all of this advice is general. Depending on your form, site design, loading pattern, user base (experienced users / internal system vs general public) etc. the best practice may be different.
So long answer short - use autofocus on the input if this is a multi step form and you think it is appropriate and obvious that the input would be the next thing to fill in.
Then test it with someone who uses a screen reader and get feedback as to whether it makes sense or if it was confusing or unexpected.
You are making a confusion between screen reader user and keyboard user.
One doesn't necessarily implies the other.
People having dyslexia but normal sight may use a screen reader so that they can hear a text out loud instead of trying hard to read it themselves, but since they otherwise use a mouse or a touch interface, they aren't keyboard users.
People having difficulties using their hands but with a normal sight might not be able to use a mouse or a touch interface.
They don't need a screen reader, but use exclusively a keyboard or maybe another specific input device that mimique the most important keys of a keyboard (in particular, tab, arrow keys, enter and escape).
A joystick in some form can be such a device.
Considering what has been said above, designing a proper keyboard navigation and optimizing it always make sense. It may not be of important use for some screen reader users, but it's very important for keyboard users, as it's maybe their only way for them to interact with the app/page.
I am a screen reader user. With others, I believe a confusion about input focus is being associated with structural and contextual concerns. To the first question regarding when to “optimize” TAB experiences. It is always important since keyboard navigation is a supporting pillar used in my toolbox as a screen reader user. In addition, any input based non-screen reader accessibility tool is likely going to use this means of access.
As a developer, a guideline I always impress on other is the fact you want the natural structure and flow of code to do most of the work for you. Secondly, the process should follow expectations of your target audience and it seems you want to follow a “wizard” style. So, let me spell out a typical expectation for a wizard style questionnaire flow when using a screen reader.
UX point: does page reload fully or dynamically change?
This matters as this has a direct impact on my current reader “cursor” and how I will navigate to find the question.
From above statements, I will assume H2 will be used consistently. Thus, I will naturally use quick navigation to go to the first H2.
Now, I will use screen reader tools to read the question (be it TTS or braille output).
Once I feel I have its meaning, I will typically use TAB to find the first input control. Buttons are not input controls and thus violates user expectations. I am looking for checkbox, radio box, text field, and/or combo box.
If check or radio boxes, then I am assuming a group and hope for grouping (sadly rarely present) and will use tactics to deal with the situation I have found. If grouped, then I am using TABs a lot to move quickly and hear the “context” of the specific box focused with input.
Finally once I have answered the question, I am looking for the next question or forward/previous mechanism. These typically show up as buttons.
Hopefully, I am demonstrating how conventions/expectation are built using basic structure rather than trying to force procedure on the user. Thirdly, sites like a11y project can be very helpful with coding.
I am working on a web page which is relatively long (4+ pages). For ease of use I have added the back to top link at the bottom of the page.
I would like to know, whether I can skip this link from screen readers or assistive tools by using aria-hidden="true" and tabindex="-1". Does this fail the accessibility criteria ?
Since the back to top arrow is visible at the bottom of the page, is it necessary to make this link available for screen reader users ? So far my understanding is home key serves as back to top for keyboard/screen reader users.
Any suggestions would be really helpful.
You shouldn't be focusing on any one single user's experience. For example, if you have that 'Back to Top' link in logical spots, it should not be taken out of tab order because you're only considering one type of user experience. A the same time, accessible features shouldn't impede on a normal experience.
That said, on a pure development basis, links should receive focus so it does fail since it's not completely operable.
WCAG 2.1.1 is pretty clear on this topic.
All functionality of the content is operable through a keyboard interface...
It doesn't say "most" functionality.
The home key works for mouse users too so why should they also have the ability to click on the "back to top" link and no one else?
I'm working on a website that has to be accessible for almost anyone.
Currently, I'm trying to figure out a way to make checkboxes accessible by different types of screen readers, using the keyboard to navigate through the content. At the moment i'm using both the standard Windows Screenreader and NVDA (see https://www.nvaccess.org/). I've tried different solutions I found on the web, but i'm still stuck and I would love some tips and trix on how to implement these sorts of features. One thing to note is that it has to work for different types of browsers (ideal would be Microsoft Edge, Google Chrome and Internet Explorer).
The ideal scenario would be something like this:
1: Navigate to the checkbox (or list off checkboxes) using the tab key.
2: The screen reader informs me that it's a checkbox, it's current state (checked, not checked), and its label.
3: Space key will uncheck and check my checkbox, informing me of my actions.
Here's two different code snippets that I've tried, but they only work on Microsoft Edge and Internet Explorer:
<fieldset id="accept">
<legend> My legend </legend>
<input type ="checkbox" id ="chbox" name ="check_1">
<label for "chbox">This is my checkbox></label>
</fieldset>
And this is when i'm using the Struts checkbox tag.
<span class="">
<s:checkbox
label="someLabel"
name="someName" id="accept" />
</span>
These work as expected in Microsoft Edge and Internet Explorer, but whenever I'm using Google Chrome, the screen readers are having trouble figuring out my content. The scenario I'm having:
1: I'm tabbing to my Checkbox, the screen readers say "Tab".
2: I'm using the space key to uncheck my checkbox, the screen readers
say "Space". (It still unchecks my checkbox though)
Apart from this, I've tried to surround my code in different divs, assigning roles and web-aria, but nothing seems to work. As I'm totally new to this, I would love some 'best-practice' ideas and tips.
Any help is appreciated,
Thanks in advance.
First, I could suggest you not to use Struts checkbox as most of them are design for legacy browser. And it may not always best for modern screen reader.
Regarding the checkbox, the recent recommendations from ARIA reference is to use DOM structure <label><input>Text</label> over <label for>.
Or use aria-label on the checkbox. But the second way is less recommend due to different support from browser/screen reader. In some bad case, they could ignore or read duplicate by different way to read the line.
Well, it's kind of a Chrome Issue.
Check this as you're not the only one.
I don't know any solution for this, I've bumped into this a few years back, luckly I just had to make it at A/AA.
It's worth mentioning that Narrator does not support third party (non-Microsoft) browsers.
Styling form elements using css can be problematic since every browser render tag in different way (just like when safari render checkbox).
Okay lets ignore safari for a while, skinning input and button are rather easy but how to completely skin select, checkbox, radio, etc.
See this pages:
Checkbox skinning
Select skinning
Radio skinning
I've heard some JS framework such as EXTJS or MooTools can do that, but i don't want a large scale framework solution, just independent JS and we can modify the skin as we like, please no JQuery solution, since i don't use it.
Any idea to do that without using some specific framework?
If you want complete control, then you generally have to replace the browser controls completely and fake them with other elements, stylesheets and scripting.
If you don't want to use a framework, then it basically comes down to DIY.
That said, the whole concept have a couple of problems.
Trying to get the controls to behave how the user expects (given input from clicking, double clicking, triple clicking, right clicking, dragging, arrow keys, the control key, etc, etc, etc) is hard.
The controls might not look as the user expects.
Personally, I'd generally try to let form controls stick to the system defaults and not try to deviate from them. Give users what they expect.
Today there are quite many javascript solutions which allow a wide range of customization for form elements styling. A quick google came up with a few nice ones:
Perhaps the best known is the Bootstrap CSS framework:
https://getbootstrap.com/docs/4.0/components/forms
https://www.psd2html.com/js-custom-forms (jQuery plugin)
https://purecss.io/forms
https://github.com/select2/select2
https://github.com/harvesthq/chosen
Checkboxes/Radios:
https://codepen.io/vsync/pen/aBOOZB
https://codepen.io/vsync/pen/wKkuz
https://codepen.io/manabox/pen/raQmpL
Today you can find many kinds of form element styling on Codepen.com
Old answer (from May 16 '09):
yes, it is quite easy.
you can use niceforms, which is independet script for making
nice looking forms, then you can modify the graphics images /
CSS as your wish.
The idea is, coding something that looks the same with same
funcionality but different design, then you need to "give it
life" with some javascript magic :)
then, you have to have ilsteners all over the place, to check
what the user clicked, than you need to reflect that same value
to the pre-hidden form element the corresponds to the "fake"
one. means, to manipulate it. then when you send the form, the
right values are places via JS.