I've
The real issue is that having those positive values set makes the bottom action-bar, and everything after it, inaccessible via keyboard nav when the quick reply is enabled. Totally screws it. The browser only recognises the two editor buttons as the last things on the page, then jumps back up to the start of the page.
If you remove the tabindex values for the quick reply suddenly everything is focusable, in the correct order (including all the editor components) right to the end of the page.
Now I realise my enthusiasm for changing code may not be regarded as suitable for a point release, but if you want to give the topic pages a quick and easy a11y boost the simplest way of doing it would be:
*And yes, my button-activated menus work perfectly with Firefox or Chrome-based browsers, on Windows desktop and on Android, with slide-out sidebars and with drop menus on the same style, while allowing animation eye candy if desired, and all on about 1 kB of vanilla js. Haven't tested with iThingz yet because I don't own any, but even Safari should find it hard to screw up.![:P]( "Razz")
The only caveat is that for uses like display_options.html it is necessary to set type="button" on the trigger, because otherwise it will adopt the default type="submit", which will conflict with the parent form. But as long as you do that it's bulletproof.
I'm just finishing up implementing my menu idea* for my own use, and noticed something else. The default quickreply_editor.html is a disaster for keyboard nav. It has tabindex="2" on the subject input, tabindex="3" on the textarea, then tabindex="6" and tabindex="7" on the preview and submit buttons. It makes no logical sense in terms of numbering, because 1, 4 and 5 are missing, but that's not the real issue.I tried to use keyboard based navigation around this topic to do some quick testing and the two search boxes are the only things that are navigable. Everything else isn't intractable which is quite surprising.
The real issue is that having those positive values set makes the bottom action-bar, and everything after it, inaccessible via keyboard nav when the quick reply is enabled. Totally screws it. The browser only recognises the two editor buttons as the last things on the page, then jumps back up to the start of the page.
If you remove the tabindex values for the quick reply suddenly everything is focusable, in the correct order (including all the editor components) right to the end of the page.
Now I realise my enthusiasm for changing code may not be regarded as suitable for a point release, but if you want to give the topic pages a quick and easy a11y boost the simplest way of doing it would be:
- Get rid of all positive tabindex values (see https://www.tpgi.com/using-the-tabindex-attribute/)
- Use tabindex="0" on the drop menu trigger spans to make them focusable.
*And yes, my button-activated menus work perfectly with Firefox or Chrome-based browsers, on Windows desktop and on Android, with slide-out sidebars and with drop menus on the same style, while allowing animation eye candy if desired, and all on about 1 kB of vanilla js. Haven't tested with iThingz yet because I don't own any, but even Safari should find it hard to screw up.
The only caveat is that for uses like display_options.html it is necessary to set type="button" on the trigger, because otherwise it will adopt the default type="submit", which will conflict with the parent form. But as long as you do that it's bulletproof.
Statistics: Posted by Gumboots — Thu Aug 22, 2024 10:50 am