tabindex and accessibility

In a very similar vein, it would be good to have aria-hidden="true" on the class="innericon" <div>’s – accessibility checkers think the icon is an unlabelled image.

Hi,

Because originally it was tabindex “0” – but then it meant, it was the first tabbable element on the page. Many users complained about that, so we agreed on tabindex 101 as possible solution.

Will check that icon to add aria attributes where missing. Usually the actual accessiblity readers recognize the hidden elements (as far as reported by a few vision impaired users). The validator tools are a bit more sensitive for it, but hopefully it should be fine.

Best,
Ernest M.

Hey! Just pitching in. Isn’t tabindex=”-1″ what you are looking for?

Note: A negative value is useful when you have off-screen content that appears on a specific event. The user won’t be able to focus any element with a negative tabindex using the keyboard, but a script can do so by calling the focus() method.

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex

Kind regards
Bjarne

Thank you for your suggestion Bjarne – I’m afraid that would not work. The issue was, that the users had to be able to focus the magnifier icon and the input field, but not as the first element on the page.

But it is only the first element on the page if other tabindex have been set starting at 1 or higher and this is bad practice for accessibility reasons:

https://webaim.org/techniques/keyboard/tabindex

In a properly formatted, accessible page, everything should be tabindex=”0″ and the elements should be arranged logically/in “reading order”. That way, when you tab through, from top to bottom, the order will aways be correct.

I don’t want to be a d!ck but if you keep tabindex set >0 in your plugin you’re favouring developers who’ve made web pages that aren’t accessible at the cost of those that have made accessible pages.

I guess you could add a setting for each instance to set the tabindex to 0? That’d be simpler than letting people set their own tabindex, I think?

• This reply was modified 2 years, 1 month ago by dtwx. Reason: Added suggestion

Thank you everyone for the feedback!

Tabindex=0 sounds the way to go here. I need to look at the source as well, because I think there will be an issue with the ordering of the magnifier and the input box. (those are ordered via CSS right now) But I think I can add a conditional logic to print them in the correct order depending on the settings, so that should resolve that as well.

Sounds like you found a solution!

I mixed up the support request with another regarding the “hidden results’ field” being tab-able – in that case, tabindex -1 did fix that, as far as I recall.

Regarding accessibility and tab order. Have you considered, changing the magnifier icon from a DIV to a BUTTON instead? That would increase the inherit semantic meaning, as well as make it totally tab-able as shown in quick screenshot:

https://paste.pics/48cbead800b4c6d62d08b87e0af793de

I know that in its current implementation, the input field is plaster AFTER the magnifier button, making the tab-order a tiny bit weird (8 and 9 in the screenshot), buuut, that could probably be addressed by outputting the elements in their logical and expected order in the DOM, and if needed, placing the magnifier before or after the input field visually using flex or grid order.

An accessible (as can be) solution is important to me and my visitors as well. I’d be happy to help testing out proposed solutions.

An @wpdreams – accessibility is about progression, not perfection – I appreciate your effort in this area.