Last modified: 2014-08-17 11:27:09 UTC
I'm not sure if many people besides me make use of the tabindex feature, which means that one can navigate through the page by just clicking the tab key, but I noted that it doesn't really make sense. The first tab index goes into the search form, which is good, then it jumps to all collapsible menus (not the menu items), and then to the page. It should probably be: search form, navigation menu (first uncollapsed, namespace tabs and then the page content. Otherwise, it takes to "scroll" through the whole page content to get to the navigation. Tested in the Vector skin of http://en.wikipedia.org/wiki/Main_Page, not sure about other skins.
I can confirm w/ Vector on en.wikipedia.org in Firefox 4.0/Linux; the main oddities are: * the sidebar *collapsable section titles* appear in tab order between the search form and the page content area, but the sidebar *actual links* appear in tab order along with the other navigation links at the *end* of the page order * getting to the top navigation links is indeed pretty hard. For that second, there's a tradeoff between making it easier to jump into the content area, and making it easier to reach the navigation links. Back in the day I think we added a semi-hidden link near the top that jumps you to the navigation links as an aid to users of text & speech browsers, but since it's hidden normally that doesn't always help keyboarders. It might be possible to force it visible too? Not sure what the ideal situation is atm.
Another silent annoyance I've had for a while now is the following: On action=edit the next tab after the editform is the editsummary. For that reason I, and probably many power/keyboard users, go like this: Edit > [tab] > work with wikitext > [tab] > type summary and/or hit Return to submit/save form (this requires the extra tab since Returns inserts a newline inside the editor instead of submitting the form, as it should). However on action=edit's where there is no editsummary or on section=new (where the "editsummary" is actually the Title/Heading, located on top of the editform rather than below it).. in those situatinos tabbing out of the editform brings you to the search form (rather than the summary, or some other place where hitting Return submits the edit form). Pressing Returnn at that point submits the search form and shows Special:Search (grrrr). This might one's your edit (granted, it would mostly happen to experienced users, who would know to press the browser's Back button and submit again (the right way this time). .. regardless, it's annoying and I end up on a search results page by the above means quite often actually... It's not entirely trivial to fix though, because it's not a high tabindex on the search form causing the problem, as much as it being the lowest tabindex on the page and editform the highest tabindex, so... after the editform (highest) the next (in most browsers that I know) tab goes back to the lowest tabindex. Not sure if it requires a new bug or if it's a bug at all, but wanted to have mentioned it!
Trevor, are you working on this and is it Normal priority? Just checking.
I'm not working on this - but I do think there are issues. The collapsible navigation headers should be focusable, but their contents should be indexed directly after them, so pressing enter to open will make it possible to tab into them, closing them by pressing enter again will make it possible to skip directly over them. The fact that the links within the sidebar aren't accesible is a horrible bug. It's not clear that the tabs are a better place to jump the user to first. When we tested frequency of use, the sidebar was used far more frequently than any of the tabs, especially the home page and random article links. The idea of collapsible navigation was originally that you could easily jump over them and onto other things (both with your keyboard focus and your eyes) by them being initially collapsed. Any sufficiently complex user interface is going to suck for tab-indexing, so perhaps we could come up with a structured approach. We could have 5 focusable items (which each play a different "role"), when you press enter on search you search, otherwise you enter a focusing state where you are now tabbing through the sub-items of the area. Press escape to leave this focus group. 0: search 1: sidebar 0+: portal headings and links in order of vertical appearance 2: head 0+: tabs, then personal tools 3: content 0+: links in the content 4: foot 0+: links in the foot There's some guidelines about how this sort of thing should be handled in the WAI-ARIA spec http://www.w3.org/WAI/PF/aria-practices/#focus_tabindex
I would like to add that for most users (not using screen readers or other accessibility tools), the usefulness and impact of good tab indexing greatly depends on the input context. When are the users more likely to be in a typing modus - and have one or two hands on the keyboard? I would claim that after searching for something, you are more probable to be in that context, then you are while browsing pages. If you are on the search result page, you most definite have just typed in something. You will also very likely want to access one of the first links in the search result (rather than make a new search). As of now, the tab indexing varies between browsers - and they do a pretty bad job at guessing correctly. At a quick glance, I actually didn't see any tabindexes in the HTML. On a search result page, you will have to have good arguments for not letting the result set have high index priority. Google understands this and does it very well as they even remove the search button (as most users know you can press enter directly in the search input field. On the search result page you'll have the hands on the keyboard, and not being able to tab down to the first result(s) is a major usability issue for MediaWiki and Wikipedia.
Can we mark this report as "easy"? Given the information in this thread it shouldn't take much work to define the focus workflow, right?
I agree. This should be fairly straightforward. (and deliver great value for the users!)
Related URL: https://gerrit.wikimedia.org/r/65115 (Gerrit Change Ie71ac23b8fe26122107e861bc44f575573bd2714)
I think that the collapsible navs should actually be tabIndex="0" role=button (integrate with implicit taborder). Our Navigation menu's are now actually properly under the H2 "Navigation menu", making them easily reachable using Header navigation features of screenreaders. (this was why we had a high tabIndex on them before). Adding 'more' tabIndexes seems confusing and unnecessary to me.
I'm pretty sure this'd be fine. I'd never heard of tabindex before being informed about this bug on the English Wikipedia's accessibility guideline talk page. JAWS doesn't seem to use tabindex to determine tab order anyway, but NVDA does,per link: http://www.w3schools.com/tags/att_global_tabindex.asp JAWS just uses the HTML order to determine tab order in that link. A semi-related problem is bug 47993 about the new notifications system.
Change 65115 had a related patch set uploaded by Nemo bis: Fix tab navigation issue on collapsible navigation menus https://gerrit.wikimedia.org/r/65115
As we already have (working) mw-jump links we should consider completely removing the tabindex from the sidebar headings so that they'll get tabbed to only after the content (or if the user select "navigation" from the mw-jump quick links). Having to tab through the whole sidebar prior to reaching the content isn't an option IMO.
*** Bug 24581 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > As we already have (working) mw-jump links we should consider completely > removing the tabindex from the sidebar headings so that they'll get tabbed to > only after the content (or if the user select "navigation" from the mw-jump > quick links). > Having to tab through the whole sidebar prior to reaching the content isn't > an > option IMO. Agreed. That's also the behaviour in monobook; I don't use Vector so I didn't notice it has a regression in that regard.
The Search Submit button does not have a tabindex. If it did, then I could use the keyboard to choose to jump to a search suggestion by hitting return, or show search results by hitting tab, return.
Do you think this task is simple enough to be a Google Code-in task? Namely, would it take 2-3 hours of an experienced contributor to fix it?
(In reply to comment #16) > Do you think this task is simple enough to be a Google Code-in task? Namely, > would it take 2-3 hours of an experienced contributor to fix it? The code change itself surely can be done in that time span, but this requires a *lot* of testing (different skins(?), also with screen readers)... and might be hard to get through code review.
Change 65115 abandoned by Bartosz Dziewoński: Fix tab navigation issue on collapsible navigation menus Reason: This extension has been discontinued, sorry :( https://gerrit.wikimedia.org/r/65115
(In reply to Gerrit Notification Bot from comment #18) > Change 65115 abandoned by Bartosz Dziewoński: > Fix tab navigation issue on collapsible navigation menus > > Reason: > This extension has been discontinued, sorry :( Anything to recover in there?
Change 134801 had a related patch set uploaded by Nemo bis: Restore search box tabindex https://gerrit.wikimedia.org/r/134801
Change 134801 merged by jenkins-bot: Restore search box tabindex https://gerrit.wikimedia.org/r/134801
Is Change 134801 tested in "action=edit" pages? The "Summary:" input box also has tabindex="1".
(In reply to Yuki Shira from comment #22) > Is Change 134801 tested in "action=edit" pages? > The "Summary:" input box also has tabindex="1". Just did, the result is bug 46336 on action=edit (tab goes from edit to summary to search). From comment 4, the relevant section is http://www.w3.org/WAI/PF/aria-practices/#kbd_layout_landmarks I think. See also comment 5.
Change 135057 had a related patch set uploaded by Nemo bis: Add search box to existing "navigation" role https://gerrit.wikimedia.org/r/135057
Gerrit change #134801 doesn't seem to be a proper fix. As I said in bug 46336 comment 3, the tabindex was set automatically (with JavaScript) determining the highest tabindex on the page, which managed to work well unless form fields were added dynamically to the page with hardcoded tabindex, as was the problem with LQT. Now, the "hardcoded tabindex=1" of the search caused the problem in bug 46336 to not be specific of LQT, but to all forms that set up tabindex on the page, whether form fields are added dynamically to the page or not, causing more problems that it was trying to solve. If we're hardcoding the tabindex also in the search, we should increase by 1 the tabindex for all the other elements of the page.
Created attachment 15472 [details] ack-grep "'tabindex' =" in whole gerrit Would tabindex 0 work? Only a special page in WikipediaZero seems to be using it.
(In reply to Nemo from comment #26) > Would tabindex 0 work? Only a special page in WikipediaZero seems to be > using it. Nope. tabindex=0 is used on elements that normally aren't focusable (like a <span>), to make them focusable when navigating through tabs, while respecting the normal tab order in the document. Only numbers greater than 0 work for specify a priority in the tab order (tabindex 0 is the default for focusable elements). What it could be done, is to use the same tabindex in all elements where the tab order matches the order where they're present in the HTML, like the edit form and such. But anyway, it requires changing the tabindex in a lot of PHP files.
Change 135205 had a related patch set uploaded by Mattflaschen: Revert "Restore search box tabindex" https://gerrit.wikimedia.org/r/135205
Change 135205 merged by jenkins-bot: Revert "Restore search box tabindex" https://gerrit.wikimedia.org/r/135205
Change 135208 had a related patch set uploaded by Mattflaschen: Revert "Restore search box tabindex" https://gerrit.wikimedia.org/r/135208
Change 135269 had a related patch set uploaded by Mattflaschen: Fix search box tabindex again https://gerrit.wikimedia.org/r/135269
Change 135057 abandoned by Bartosz Dziewoński: Add search box to existing "navigation" role Reason: This is not going to work / help, sorry :( (And there are so many patches for this issue, let's thin the herds a bit.) https://gerrit.wikimedia.org/r/135057
Change 135208 merged by Reedy: Revert "Restore search box tabindex" https://gerrit.wikimedia.org/r/135208
We should consider possible options we have other than lastTabIndex. According to http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex , positive tabindexes are first (this is how it works with lastTabIndex). Then come tabindex 0 elements, which come in character stream order. This could work, since navigation comes late in our document. However, I think 0 tabindex is equivalent to omitted in most cases. That also raises the important question, why exactly is an explicit tabindex needed here (I don't have OTRS access)? In Firefox and Chromium, it seems that the search box included in the actual tab order anyway, and late in the page. Is the goal to make search late in the tab order, but still before the navigation elements with no tabindex (e.g. Read/Edit tabs)? Could we potentially solve this by having a dedicated tabindex range for navigation elements in particular areas of the page? We have 0 and 32767 available according the W3C, and it doesn't have to be contiguous, so reserving ranges would seem to be doable.
(In reply to Matthew Flaschen from comment #34) > We should consider possible options we have other than lastTabIndex. > According to http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex > , positive tabindexes are first (this is how it works with lastTabIndex). > > Then come tabindex 0 elements, which come in character stream order. This > could work, since navigation comes late in our document. However, I think 0 > tabindex is equivalent to omitted in most cases. These rules are changed in HTML5 (http://www.w3.org/TR/html5/editing.html#sequential-focus-navigation-and-the-tabindex-attribute), so we need to consider that, and how browsers are actually implementing it.
(In reply to Matthew Flaschen from comment #34) > why exactly is an explicit tabindex > needed here (I don't have OTRS access)? In Firefox and Chromium, it seems > that the search box included in the actual tab order anyway, and late in the > page. To move the search box's position in the tab order to the beginning rather than near the end of the page.
Change 135269 merged by jenkins-bot: vector: Add tabindex back to search box https://gerrit.wikimedia.org/r/135269
[No patches left here - resetting bug report status]
