Accessibility improvements for vertical tabs

Thanks a lot for looking into this, mohammed!

Do you have any specific recommendations that we could do to help make this more accessible while retaining the overall usability improvement that it offers to our sighted users?

The justification for moving to this approach was:

a) Collapsed fieldsets did not provide enough context to know what it was they were really saying. "Revision information?" What's that? So users would expand *all* fieldsets to discover what was there, leaving them with a monster form that is 3x the length in their wake.

b) Vertical tabs allow you to check, without clicking into a fieldset, whether or not the setting you want to change is already done. For example, if you're adding a node and can't remember if you checked the "Promoted to front page" checkbox, you can scroll down and read the description of the tab and it will tell you.

c) Probably something else I can't think of right now. :D

So if we can retain those qualities and still improve your user experience, I'd be very interested to know how. :)

hi webchick! thank you very much for explaining the gain this makes for sighted users, because i was wondering. well, the only thing I can recommend is perhaps improve the tab order when avigating those tabs? like when I click "menu settings" then erow down, or press the tab key I would land on to the form, rather than land on the next tab as is the case now.

however, the new status discription attached to those vertical tabs is a plus even for us screen readers. very useful to know without having to expand the tab. as I said, I don't find this very buggy, and I can certainly live with it. it just took some getting used to.

Hey mohammed76,

This is a related issue - http://drupal.org/node/323112

Don't think it's a duplicate issue, but wanted to tie them together.

Apologies for not getting to test this sooner. But, IMO there are accessibility problems with vertical tabs.

1. As a screen-reader user there is no way for me to know which tab is selected, or what clicking on the link to show / hide each tab will do.

2. I expect that if I click on a link that will show content, that the content will be somewhere near the link, it took me some time to figure out where the display content was.

Recommendations

1. There needs to be clear non-visual indication that this is indeed a tabstrip.
2. There needs to be non-visual indication of which tab is active.
3. There needs to be an easy way to find the displayed content once a tab is selected. This problem may become an easier task if 1 and 2 above are solved.

See #323112: Vertical Tabs

Somewhat Related Issues:
#521852: Local tasks lack semantic markup to indicate an active task
#541568: Link to expand / collapse fieldsets has poorly accessible link text

Subscribe.

Could problem 3 be solved by having an anchor at the top of the tab content and setting focus there (in addition to the JS switching code)?

subscribing

Subscribing. I love the look of the new tabs, I'm sure they can be made to work well with AT also.

Ok, we haven't got the examples in core yet, but want to make sure we've got the right models yet for these:

1. There needs to be clear non-visual indication that this is indeed a tabstrip.
http://drupal.org/node/545610#comment-1931830
Adding this to the top of the tabstrip:

2. There needs to be non-visual indication of which tab is active.
http://drupal.org/node/521852#comment-1969646
Adding something like this to each of the vertical tabs when selected:

This does make me wonder though if having two 'active tab' strips in an edit page is going to be confusing. Maybe that phrase isn't good.

3. There needs to be an easy way to find the displayed content once a tab is selected. This problem may become an easier task if 1 and 2 above are solved.
http://drupal.org/node/467296#comment-1967328
Having an anchor at the top of the tab content and setting focus there (in addition to the JS switching code)

Is this the right approach?

If all else fails, could we use anchors to allow screen readers to skip the links and go straight to the tab content?

If these can be made to work well for users accessing the non-visually it'd be a really good day.

+1 for @Garrett Albright's suggestion if all else fails.

Ok, I think that I have a solution for the first problem with this patch to form.inc It just adds the following to the top of the vertical tabs. Might be that there needs to be a more generic name for it, but:

I've been looking into the second problem and have real problems as I don't know and playing with the AJAX in misc/vertical-tabs.js isn't working too well.

I believe that the Drupal.verticalTab.prototype function is what is applying the class selected to the lists of vertical tabs.

I'd been hoping to add something like this to this function, but it didn't work at all:

I really don't know what to suggest and have no idea how to remove this when it is unselected.

I think we'd be able to extend this inserted text to include an anchor to the tab content @Garrett Albright but for this code here:

I'm thinking it should look like:

This does need a lot more thought (and someone who understands aJax!

Mike

Excuse me, but the /small tag isn't permitted in XHTML because it's a esthetic tag. It must be changed with the /span tag like:

Ramon

@mgifford

It would be nice if there was a way to either make the heading more generic, like 'Vertical tabs' or to provide the ability for the name to be set on a case-by-case basis.

One thought of an approach to append the text (activ tab) to the active vertical tab is.

1. Append <span class="active-tab-text element-invisible">(active tab)</span> to each tab.

2. When the page loads use a jQuery selector to set all of the above tabs to display:none jQuery.hide().

3. Use jQuery.show() to show the active tab.

4. When a new tab is selected repeat steps 2 and 3.

Possible problems:

1. Anyone with CSS disabled will see (active tab) on all tabs.

2. A different class would need to be used on the tabs for each vertical tabstrip on the page.

Alternate approach.

1. Store a global JS variable that points to the selected tab and append the span above to that tab, a different global variable would need to be used for each vertical tabstrip on the page.

2. When a new tab is selected remove the span from the formerly active tab and repeat step 1.

Ok, a bit more progress here. @Everett Zufelt I changed the text to 'Tab strip' which is more generic. Agreed it should be something that you can set manually though to provide meaning.

@rvilar I'm not arguing for the /small tag, but it's what's in the code now. There are a few other references to it here too:

I did find it quite interesting to learn that AJAX is adding in the summaries however using module specific files:

Could make it easier ot insert accessibility tags, or not.

Mike

adding tag for vertical tabs

Is there any reason not to make this RTBC even though it's only a partial solution?

I'd sure like to see better ways to identify active tabs and skip through to the relevant content, but info hasn't been forthcoming on that here.

@mgifford

I think that it would be best to wait until there is a more thorough patch, that addresses all issues here. The patch that is currently proposed is good, but I believe it can be commited after code freeze.

As Everett and I have been discussing, I'm actually working on a JQuery-ish patch for this issue right now...I'm on my way to a long-term solution along the lines of Everett Zufelt's and Garrett Albright's suggestions that is addressing the serious concerns here. It's my goal that this patch a) will not require major API changes and b) will not have any negative impact on the vertical tabs as they are visually styled now.

It looks like it won't be ready for thorough consumption and therefore robust review by tomorrow, but I should have it ready for review very shortly thereafter.

Thanks for the update. We're looking forward to seeing it!

FYI #567390: Use vertical tabs with keyboard only

with some ajax added for displaying active tab

@mgifford: God bless you. Admittedly I haven't been able to devote the time I'd like to this issue in the last week, but I'm so glad that you've come up with an AJAX solution and one that looks very elegant at that. I'll shelve my code on this unless and until it may be needed. :)

That happens. I don't know jQuery but was able to look at @attiks code to get the results.

I think this patch deals with issues 1 & 2, but doesn't hit on 3 yet from comment #4.

Now, there still needs to be a way to link the menu to the content with the pane.

I don't have any good ideas on that.

@kat3_drx, thanks for the review of the patch. Did you have any trouble installing it?

This is a nice patch. I think that it would make things more accessible if the "(active tab)" text was part of the link text for the tab, and not a separate element.

Reasoning behind this is:

1. When tabbing through the links with a screen-reader the (active tab) text is currently not read, as it is not part of the link text.

2. When arrowing through the links active tab is read after the active tab, and before the next tab, users may be confused as to which tab is actually active.

3. To be more consistent with the solution proposed of active tabs for local tasks at #521852: Local tasks lack semantic markup to indicate an active task.

Mike, it looks like I need to sit down with your latest patch before I get too deeply into this. But here's a thought: These vertical tabs are essentially flyout menus, except that forms, not submenus, are the content revealed on flyout. How do screenreaders get to the content when the tab in an accessible flyout menu is clicked? Or is the accessible flyout menu one of the great unsolved problems of modern Web design?

@mgifford: nope, no trouble at all installing the patch! It works like a charm for issues 1 - 3. I do have some JQuery code from a previous example that I can roll into a patch for issue number 4 and bring on here for review early next week. It's somewhat like what Cliff is talking about; accessing the flyout menu but using that as a trigger for additional markup, if that makes sense.

I'm just not sure how to adjust the jQuery to have the (active tab) show up within the link text. I understand how that would be better, but don't have a sense of how to do it.

@#25

Hi Everett,

Would it help, if the text would be additionally provided as a "title" attribute on the links (see http://reference.sitepoint.com/html/core-attributes/title )?

Frank

@Frank

Thanks for your comment. Unfortunately the title attribute is not well supported by assistive technology, and is inconsistently supported by the AT which does support it. See H33: Supplementing link text with the title attribute | Techniques for WCAG 2.0.

Just some more ideas off the top of my head:

1) Using tabindex or access keys.
2) The jQuery code in vertical-tabs.js mainly changes HTML and CSS classes/ids. What about using some more of jQuery's event handlers for navigation (e.g. keyboard short-cuts)?

Frank

@Frank

The ideas that you have suggested may indeed be part of the solution. I would still like to have a keyboard only (non-screen-reader) user do some usability testing with the current implementation so that we can determine what changes need to be made.

One question:

Shouldn't the keyboard only behavior be the same with JavaScript turned off?

@mgifford re: #28: what about storing a variable or triggering an action based on the content box that the vertical tab is attached to, ie when that changes, the active tab variable changes within the link text. I haven't gotten a good sense of how the content of the tab is changed or swapped out in core, but what do you think?

@Frank - are you wondering about setting tab order for keyboard users? Not sure what the context is. It's probably a good precedent though.

@kat3_drx That might be doable. My jQuery is getting better but it's still pretty rough though. I'm not sure what the best path is. Not sure who developed the vertical tabs in the first place, but it would be useful to get some experienced jQuery support here to see that this is done properly. We're closer with the patch in #22, but it should be much better!

I don't know whether this will help solve #25 but I deem it at least a more semantic solution. Instead of using unordered lists like this:

we could use definition list like so:

A similar approach has been suggested in #323112: Vertical Tabs (#23), but for the whole tab content not only the summary.

@Frank

I don't think that will solve the problem in #25. I'm not absolutely sure though.

There's also a problem in that there are 3 not two types of data.

The title, the summary & the new tab content.

Are you referring to this comment? http://drupal.org/node/323112#comment-1079086

@mgifford

Yes, that's the one, #23 (mixed up the numbers with the other #25).

The new tab content seems to be the old fieldset, only pushed to the right to make room for the tabs.

Following my own suggestion from #31 this little patch adds a "tabindex" attribute to every list item.

The nifty thing is the index of "-1". This will indicate that the item is tab-navigable without putting it in any actual tab order. Tab key and shift-tab let you navigate back and forth among the vertical tabs.

What's left to do is selecting the active tab's content. I would suggest right arrow key or enter key. That behavior has still to be added using jQuery.

Cheers,
Frank

BTW
I learned that trick from "The JavaScript Anthology" which contains a very good chapter 16 on "JavaScript and Accessibility" (http://www.sitepoint.com/books/jsant1/)

This updated version of my patch follows the suggestion in #36 and changes the list for the tabs to a definition list. The respective CSS was also adapted but might need some additional fine tuning.

TODO:

1. Adding behavior for selecting the tab content.
2. Getting rid of the "junk" href values <a href="#"> which might pose a problem for screen readers which will regard them all as pointing to the same page and will announce them as "visited links" after the first one was activated.

Can you re-upload that last one. It's a 0 byte file.

Oops, sorry. Here it comes again.

And here's the next one:

I added a keyboard event so that releasing the enter key will open the tab content. Note that this is far from perfect as there is still no way to get directly to the fields of the opened tab using your keyboard. Instead you have to go through all of the tabs first.

That might be amended by giving the form elements of the open tab tabindex values with a higher priority or using another key for that kind of navigation.

All those patches need further testing in different browsers. I only tested with FF3 and IE6 on Windows 2000.

(FYI The patches are cumulative, i.e. this last one contains all three modifications mentioned above.)

Mike, if you can add one of these patches to your dev site, I would be happy to test tab behavior and do my own accessibility evaluations. I'm starting to feel a lot better about this issue. Thanks much for your help, Frank!

Frank, have you looked at the code behind http://www.harvard.edu/?

They do something similar with menus, and I think you can tab from the selected topic's tab (need a different term) to the corresponding subtopics without going through all the other tabs.

I could be wrong, but it might not take you long to check their site's behavior and then their source. (Their tabs are horizontal, but I think the same approach would work here.)

Thanks for the link, Cliff. I had a quick look at the menu and they have the other problem: You have to tab through all of each tab's items to get to the next tab...

Each tab is a crossroad and it's difficult to decide which is the desired behavior for tabbing: Going to the next tab or going to the current tab's content.

I think the best solution is to use different keys for each action. Is there some canonical way?

OT

Is there a way to subscribe to this issue to get new postings by e-mail?

[EDIT] Forgot that we're not on groups.drupal.org here and just found the usual subscribe link on the project page...

There are similar efforts under way at #567390: Use vertical tabs with keyboard only.

The other related Issues:
#323112: Vertical Tabs
#521852: Local tasks lack semantic markup to indicate an active task
#541568: Link to expand / collapse fieldsets has poorly accessible link text
#569080: To change the tabindex on vertical tabs or not?

We better join forces - where's best?

Has anyone performed usability testing of vertical tabs with a keyboard only user to see what actually should be modified?

@Frank

There's also just looking at your issues here http://drupal.org/user/216048/track

I regularly start by looking at issues I've commented on in the past just to see if there's an update.

These are available via rss I believe.

@Frank:

What if we use two approaches — tab order plus headings? I don't have time to figure out which heading level just now, but here's the idea:

1. Make each vertical tab's text a heading 4 or 5 or 6 — wherever it fits in the page heirarchy; just something to get it into the semantic structure.
2. Set the tab order not to go from one vertical tab heading to the next but to go from the vertical tab heading to the first form field associated with it, then through those form fields, and then from the last of those fields to the next vertical tab heading.

Then the keyboard-only experience takes you through all tasks (considering each individual form input field to be a "task") in order, and screen-reader users can at any time ask for the heading structure of the page to find the next (or any, actually) vertical tab.

Doable?

@mgifford RE #50

Thanks for the tip! I've been using http://drupal.org/project/issues/user but the track page is even better. And yes, I should be using more RSS feeds... ;-)

BTW I use the "Morning Coffee" Firefox add-on (https://addons.mozilla.org/en-US/firefox/addon/2677 ) for having a look at such pages first thing in the morning.

Cheers,
Frank

@Cliff

These are interesting sounding suggestions. At the moment the code and behavior seems to rely heavily on the tabs being links with a fake anchor tag <a href="#"> for using CSS pseudo-classes like :hover for their behavior. Changing that to using headers should be possible but might need some more work than the other approaches.

However, I agree with Everett (#49) that me need some input from keyboard only users to decide which is the best approach.

Cheers,
Frank

I'll ping Jim Thatcher. He could give us a lot of insight.

hello,

@mike, have the latest patches been installed at the dev site? I could deffinitely look at it from a keyboard only user perspective.

@Cliff,

This is doable and was my attempt in #567390: Use vertical tabs with keyboard only except for set the headings, for me this works the best but we need to know what the general user wants. If there's an agreement I'll adapt or merge the patch

Waiting for input from potential users is great if we know where we can get those users. Also, we need to be sure we realize who is being helped most by each element. I'm thinking:

• Making the tab text into headings primarily benefits people who use screen readers. It gives them a handle for navigating from item to item without having to go through each form associated with every item.
• Setting a tab order for the tab text and form elements benefits not only people who use screen readers but also people who can see but cannot (or choose not to) operate a mouse, touchpad, or similar device. I don't think it would make any difference to this group whether the tab text is also set up as a heading.

So those are the groups who would need to user test it, right?

The more I think about it, the more it makes sense to make the tab text into headings: We have some kind of (hidden) heading that identifies that group of tabs for people using AT. Each tab item groups related content; therefore, from a semantic standpoint, each tab's wording is a subheading to the hidden heading we have applied to the group of tabs.

Everett, wouldn't that make sense to you from the standpoint of a JAWS user? I don't think that would cause navigation problems for JAWS users. Am I right?

Some more thoughts in that direction:

1. The tab texts stem from <legend>elements of the original fieldsets which are indeed a kind of heading. So rendering them as headings on the tabs would be in line with the general semanctics.

   That should also get rid of the "fake" anchor elements mentioned above.

2. The above mentioned "JavaScript Anthology" (#39) points to the fact, that the vertical tab system is really a two-dimensional structure where you cannot only move up or down but also right (entering) the tab and left (leaving) the tab. Tabbing on a web page is a one-dimensional operation where you go from one active element (link, form-field etc.) to the next, either in the default tab order of the page (depending on the browser?) or set by defining tabindex on the respective elements.

   The obvious and intuitive choice for two-dimensional navigation are the arrow keys. So vertical tabs could use the arrow keys for navigating between the tabs and its content and leave the tab key for moving between the form fields on the active tab. However I don't know whether this behavior is in line with screen readers and other AT.

Cheers,
Frank

@Frank, two remarks
1/ Using arrow keys to navigate will be a problem since people use arrow keys inside textboxes, textareas and radio buttons to navigate and/or select

2/ When using a screenreader i don't think people there's a knowledge of left/right so for those users it doesn't really make sence to press the right arrow to enter the tab content.

One remark about changing the taborder is that as it is now you can easily skip all the tab content by just tabbing down, so if you don't want to alter anything inside the tabs you can quickly tab through and hit the save/submit button. If we change the tabindex or force people to tab through all the tab pages this will take longer. Unless of course if we provide a general shortcut key for the submit/save button, but I guess this is out of scope for this patch.

@attiks, Everett could address this better than I, but I believe people who use screen readers do use left and right arrow keys for some operations — for example, navigating within tables in "Tables" mode. So I think Frank might be on to something there.

Also, however we fix the problem of navigating within tabs, we could easily add a skip link before this feature and point it at the save/submit button. Technically, that might be outside the scope of this issue, but, if so, I would think it's a trivial distance to cover to fix a vexing problem that clearly is within scope.

@Frank, since I'm not actually looking at the code (haven't figured out how to do that, for one thing, and it tends to look like a lot of gibberish to me after a while, for another), I didn't realize that the tab text was actually a fieldset legend. I'll have to do a little research to see if we would be violating an important principle by embedding headings in fieldsets. (I'm not sure.)

Finally, Jim Thatcher has let me know he's on vacation. I'm not sure when he's returning, but I hope we can continue thinking through possibilities and eventually have a prototype for him to test.

@Cliff

The jQuery code does the following AFAIU:

• stripping not needed parts from the original fieldsets
• pulling content from the fieldsets for re-use (e.g. the legend for labeling the tabs)
• "stacking" the fieldsets one upon the other
• creating the vertical tabs - from the fieldsets' legends - for accessing the fieldsets

Come to think of it, pages with normal fieldsets might be more accessible when tabbing through the fielsets's legends (like tabbing through the vertical tabs) and "entering" the fieldsets only if one wants to change its settings. That way the tabbing experience could be more concise with JavaScript turned on or off. But that's another issue (and might be related to #541568: Link to expand / collapse fieldsets has poorly accessible link text).

EDIT:
The default behavior of collapsible fieldsets is:
* You can move between the closed fieldsets using tab/shift tab.
* The enter key toggles opening and closing of the focused fieldset.

Glad to see all of the thoughtful comments here.

I think that one important thing we need to keep in mind here is that vertical tabs is a complex UI component, or widget. We are asking the browser, and to some extent the user, to perform in a way that the html spec did not originally anticipate. IMO we should keep custom keyboard commands (left / right arrows) to the absolute minimum, to reduce the learning curve on users who encounter this type of component.

Some questions which need to be answered.

1. When a tab receives keyboard focus does the styling of the tab change to look the same as if it were being hovered by a mouse? This will give a clearer notification that a tab (link) has focus.

2. Is the hover / focus style sufficiently different from the non-hover / focus state that it is perceptible?

3. Can a user tab through the list of tabs and get to the content of the selected tab and the remainder of the page content which comes after?

4. Can a user tab back up to the tabstrip and select a new tab to then repeat the steps in #3?

@Everett

Thanks for your input!

AFAIK only 4) is possible yet (at least with my patch).

I am working on 3). At the moment you can only open the tab by hitting the Enter key but not get to the content yet.

I noticed that this is also difficult/impossible without vertical tabs but with the usual collapsed fieldsets: You can tab through the legends of the fieldsets but cannot open them using the keyboard (but perhaps I'm missing something there).

1) and 2) are important aspects I haven't thought of yet.

EDIT:
Regarding 1) and 2) I just added some background-color settings to vertical-tabs.css (not yet in patch, as my choose of colors might not be ready for production use...):

Cheers,
Frank

@Frank

I have had no problems expanding collapsed fieldsets, or vertical tabs, via the keyboard. I am using a screen-reader, but I don't see how this would be different for keyboard only users without a screen-reader, unless the links themselves are not receiving focus.

@Everett

I have no experience with screen-readers and none at hand. I am only using the screen-reader emulator "Fangs" for Firefox (http://www.standards-schmandards.com/projects/fangs/).

Which keys are used for navigating with a screen-reader? Are they the same across all different screen-readers?

@Frank

Navigation keys are different across screen-readers. generally tab should take a user through the focusable items on a page, in the DOM / tab order. You may want to look at the opensource NVDA screen-reader sometime http://nvda-project.org

Thanks for that hint, Everett. (It takes some getting used to getting one's whole desktop read aloud, though... )

I updated my patch:

1. You can tab back and forth between the tab buttons.
2. When you press the Enter key the focus changes to the first input field of the selected tab pane.
3. You can tab through the input fields in the usual order.
4. If you press the Escape key you get back to the selected tab button.

However, there are still some issues:

• After the last input field of any tab pane, tabbing will bring you to the Save button. But this might very well be a desired behavior. The reason is that all the tab buttons (the list in markup) come before the tab panes in the DOM.
• Doesn't work on the "File attachment" field yet.

I'm glad to see some good work really getting done on this. Work obligations have kept me from devoting any kind of decent coding time to this, and promise to continue to do so, so I'll disengage myself from the code for the time being and apply Frank's awesome-looking patch ASAP. ^^

1. You can tab back and forth between the tab buttons.
2. When you press the Enter key the focus changes to the first input field of the selected tab pane.
3. You can tab through the input fields in the usual order.

* This all sounds good

4. If you press the Escape key you get back to the selected tab button.

* How will a user know about this behavior?

However, there are still some issues:

• After the last input field of any tab pane, tabbing will bring you to the Save button. But this might very well be a desired behavior. The reason is that all the tab buttons (the list in markup) come before the tab panes in the DOM.

* This is what I would expect as behavior. The only way that this would differ from a vertical tab UI in most desktop applications is that once on the Ok, Cancel, etc., buttons tabbing again would normally take a desktop app user back to the list of tabs. I am comfortable with this being omitted, as doing otherwise would 1. not be what most browser users are expecting, and 2. make it difficult to get to any focusable elements past the tab pane.

• Doesn't work on the "File attachment" field yet.

* Can you please explain the behavior that occurs with the file attachment field?

changing this to needs review by bots. I think it may need to be re-rolled to get by them, but want to have them validate first.

The last submitted patch failed testing.

Ok, this should get by the bots, but it should be no different.

Functionality still seems to work in this patch but I haven't done much testing of it.

Don't know if this affects the current patch, but I need to respond to an item in #67:

4. If you press the Escape key you get back to the selected tab button.

* The "Escape" key stops the screen reader — at least, that's what it does in JAWS — so it isn't available for other functions.

I agree with Everett that the transition of focus from the last item in a tab's pane to the "Submit" button is a feature, not an issue — so long as the next tab does, in fact, bring the focus back to the list of tabs. So long as focus doesn't shift from the "Submit" button to, say, the url, we're in good shape.

Of course, we do need to fix whatever problems we're having with file attachment.

Glad that I could help. Just some short remarks:

* Escape key
As a Windows user I know the Escape key as kind of "emergency button" which brings you back to where you came from. Changing this key is just a matter of changing its keycode in the jQuery code (http://www.js-x.com/page/tutorials__key_codes.html). You could also assign more than one key for that function. Perhaps it might even be possible to make this configurable if Drupal had something like "Accessibility settings".

* Semantic markup
There are still some more suggestions around regarding improving the semantics of the underlying markup for the vertical tabs (e.g. making them headings). My patch uses definition lists. There might be some more evaluation necessary in that direction.

EDIT
* File attachment field
I suppose there's another focus() event handler getting in the way because the default behavior is opening the Browse dialog box when clicking in the field.

Cheers,
Frank

We've got to find a solution for all input fields including the file attachment field before this can get in.

I'm not a jQuery person so have limited insights here.

However, I did a quick grep to see if I could find files that might be responsible:
grep -r focus misc/tabledrag.js misc/vertical-tabs.js modules/ | grep .js

Unfortunately this came up blank for me. However I don't really understand the vertical tabs javascript. I've just been hacking it.

Not sure about the escape key solution. Arrows work don't they? Think they'd be more natural than hitting escape.

I'm wondering if we can get agreement on some of these enhancements and get an improvement in core. With that and more testing hopefully we can figure out the rest before Nov.

@Cliff

The escape key does stop JAWS, but only because it is being used to invoke a new operation. When JAWS is in forms mode the escape key will exit forms mode. Otherwise, the escape key is passed through to the application. That is, using JAWS I can press the escape key to interrupt a page loading in IE / Firefox.

I really don't belive that we need to provide a keystroke to bring the use back to the vertical tab list. Users are capable of shift-tabing back to the list. Any automated tab-ordering would make it confusing, if not impossible, to get to the remaining focusable elements on the page. And, any keystroke to jump to the list of vertical tabs would be non-intuitive, and rarely used, by users.

@frank

On an unpatched version of head does the file browse dialog open when tabing to the file attachment field? I don't think that this is desirable behavior and a separate bug should be filed against that if it is the case. If, however, it is something in the patch that we are working on here that is causing the file browse dialog to open when the file attachment field receives focus then we need to track down and correct the problem. I myself have never experienced the behavior you have described in d6 / d7, but I don't know if I've used the file attachment field in d7, and I have not applied this patch.

I went back to an unpatched version and tried key navigation again.

@mgifford

* Not sure about the escape key solution. Arrows work don't they? Think they'd be more natural than hitting escape.
- Arrow keys don't work for me (XAMPP, Win 2000, FF3). So this might be a substantial difference between browsers and screen-readers.
- And #59 gives some reasoning why arrow keys can/should not be used for navigating between tab panes.

@Everett

* On an unpatched version of head does the file browse dialog open when tabbing to the file attachment field?
No, only when I set the focus using the mouse. I tried this with JavaScript turned off. FF3 still shows this behavior. IE6 works ok, also with patch. So this seems to be browser related. We really need some thorough browser testing.

* I really don't believe that we need to provide a keystroke to bring the use back to the vertical tab list.
- I would prefer such a short-cut key to shift-tabbing back, but that's my personal preference.
- Shift-tabbing back will bring you to the beginning of the currently open tab pane but then not to the corresponding tab button but instead start tabbing back from the last tab button. That's because of the DOM order mentioned above (#67).

Looks like this still needs more discussion...

Edit: LOL Sorry. I thought this was in the RTBC queue. :D

@Frank

I think that the file attachment issue needs to be left separate from this issue, as it is a browser issue, which does not seem to effect accessibility of the vertical tabs UI.

As far as the tab order you have described above, it is acceptable to me and should be understood by users. If we provide a keystroke to return to the list of tabs how will users be informed of the keystroke?

I think that the following needs to be done in order to make vertical tabs resonably accessible, perhaps other additions would be nice, but we're getting down to the wire on D7 api changes.

1. There must be an indication of which tab is active (both visually and for screen-reader users. Ideally the indication for screen-reader users is part of the link text.

2. The :hover :focus and :active states of the tabs must provide the same visual effect and have a sufficient visual contrast to the non-focused tabs to be perceivable.

3. Users must be able to tab through from the beginning of the list of tabs through to the end, and then through the contents of the selected tab and out of the UI component to the remaining focusable elements on the page.

4. Users must be able to reverse steps in #3.

@webchick: Oh, how we wish!

@Frank: Everett has summed up the challenge quite well. I would like to reiterate what he has said about the active tabs being identified in a way that provides sufficient contrast to the other tabs. Somewhere — were we discussing this in the Accessibility group? I can't find it if we were — I pointed out that in the Seven theme the only way a person who needs high contrast can tell which tab is active is to look for the one they can't read:

• There is too little contrast between the shading of the active tab and the shading of the other tabs for it to be discernible to people who have poor vision. (The active tab is only slightly darker.)
• There is barely enough contrast between the text in the tabs and the (lighter) background of the inactive tabs for the same people to read that text.
• The background of the active tab is just dark enough to make the text in that tab illegible to many people who need high contrast to read. (When the setting sun reflects off my monitor, I'm one of them.)

I would really like to see something like the attached image, in which the font for the active tab's text is bold and a high-contrast arrow points to the text. I don't know what it would take to do it, but I think this approach would make the active tab obvious even in the low-contrast themes that seem to be so popular in Drupal today. (There would also need to be hidden text to identify it for people who use screen readers.)

Whether you come up with this precise solution is not important. But it is important that the solution present the information this clearly.

@Frank: I think shift-tabbing is the normal way for people who navigate with the keyboard only to back up. I will look into this more this weekend. But just for clarity, where you said:

- Shift-tabbing back will bring you to the beginning of the currently open tab pane but then not to the corresponding tab button but instead start tabbing back from the last tab button. That's because of the DOM order mentioned above (#67).

In the attached image, where Tab 3 is active and let's say the cursor is in the second form field associated with Tab 3, what exactly are you saying that shift-tabbing would do? Take me through the results of three or four shift-tabs, if you would, please.

Subscribe

Been busy the last few days, will have a look at your comments ASAP.

EDIT:
Just some pointers to relevant documentation:

Non-Traditional Navigation
http://drupal.org/node/464492#keyboard

Keyboard Accessibility
http://www.webaim.org/techniques/keyboard/

Cheers,
Frank

Hitting the virtual subscribe button!

@Cliff

We're discussing at least three different aspects regarding the accessibility of vertical tabs at the moment:

1) The underlying markup and its semantics (e.g. unordered list vs. definition list; headings vs. links).
2) The behavior of the tabs for non-mouse navigation (achieved using jQuery JavaScript).
3) The appearance of the tabs (hover state and the like), achieved using CSS.

ad 3):
One idea would be to use System Colors (http://www.iangraham.org/books/xhtml1/appd/update-23feb2000.html). That way the color/contrast scheme would be independent from the theme used and would provide for some configurability for the user. That will need some thorough cross browser checking.

If we go that route all these accessibility enhancements might better be provided by a new (core) module than hard-coding them into core. That might even provide for enhanced configurability (e.g. by letting the user decide which keyboard keys to use or which color-scheme).

@Frank, even though I really have my heart set on the arrow, relying on system colors could work. (Technically, couldn't each tab have the arrow in it, but only the active tab have the system color of the arrow set to "active"? In the inactive tabs, the arrow would share the color of the rest of the tab, so it wouldn't show up. So long as the active tab also had a hidden label that screen readers would pick up, I think that would work.)

I realize this is asking a lot. If that means that particular feature needs to be a D8 fix, so be it. Just fixing the keyboard navigation and adding a text label to indicate the active tab for screen readers would be a huge improvement to get into D7. (So that means we're talking about only at least two problems to solve.)

;-)

Oops. Saved twice! (Working too late.)

@#85:

1) Underlying semantics - unordered list vs. definition list

The unpatched version will be rendered by screen-reader emulator Fangs as:

List of seven items
bullet This page link Menu settings Not in menu
bullet This page link Revision information No revision

The patched version will be rendered as:

Definition list of seven items
This page link Menu settings equals Not in menu
This page link Revision information equals No revision

Some remarks:

1. Is this the same behavior as with real screen-readers?
2. The fake anchor tags <a href="#"> are read as "This page link" which doesn't provide any semantics at all (see # 53). If we could get rid of those the patched version would read without any "noise". Seems to be related to #541568: Link to expand / collapse fieldsets has poorly accessible link text.

2) Behavior of the tabs for non-mouse navigation

I still struggle with the question what the expected behavior of screen-reader users is. Which keys do they use for accessing a link? How do they know which keys to use for what action? Any indication we give on the page will clutter the page for normal users and might be useless for blind users. Using "Access Keys" might be an option but might suffer from the same restrictions (http://en.wikipedia.org/wiki/Access_key).

3) Appearance of the tabs (hover state and the like)

IMHO we should provide only some basic styling with vertical-tabs.css. After all, this is a theming issue and the preferred display of the tab buttons depends heavily on the user's preferences (contrast, color-scheme etc.).

Perhaps we should move some of the preliminary findings of this thread (if there are any...) to some documentation page?

Cheers,
Frank

@Frank

I appreciate the thought that you have given this issue. However, I think that you may be overcomplicating things. I still feel that a patch that addresses the points that I made in comment #79 would go a long way to improving the accessibility of vertical tabs.

To clarify 79.1, the text for screen-reader users would likely be best included in the anchor element as something like this: <span class="element-invisible">(active tab)</span>. The .element-invisible CSS class is defined in system.css and appropriately makes elements invisible to sighted users, while leaving it available to screen-reader users.

The last submitted patch failed testing.

@Everett

You're right. Otherwise this might become a sad case of Centipede's dilemma ;-)

But I don't quite know what to make of the system's error message: "Failed: Invalid PHP syntax in misc/vertical-tabs.js". This is a JavaScript file so what's it to do with PHP syntax??

Think the bot was just having a bad day. Setting it to needs review.

I have created a new patch which incorporates some of the suggestions made above:

1. I dropped the Escape key in favor of the Enter key to get back from the selected tab pane to its tab button. That mimics the behavior of the collapsible fieldsets.
   NOTE: Full toggle behavior is not yet implemented.
2. For highlighting the selected tab and hover state a mixture of outline and system color ("Highlight") is used which should give sufficient feedback to all users. The outline color is inherited so should fit into each themes color scheme.
3. I streamlined the jQuery code, e.g. using keydown event instead of keyup as this should work more reliable across browsers.

Please test these changes.

Cheers,
Frank

TODO:
- #89 is still to be addressed.
- Apply the CSS changes also to the RTL version of the stylesheet file.

The last submitted patch failed testing.

Same patch, this time with correct UNIX line endings, sorry.

For those of you who don't have a Drupal 7 installation at hand to test this patch I created a screencast with CamStudio in SWF-format. It's a bit rough but should give you an idea what we're talking about.

It first shows the tabbing behavior using the keyboard and then the hovering behavior using the mouse.

Cheers,
Frank

Sadly the enter key isn't going to work as it's needed for any text area boxes that would enable two lines (but with this ajax moves you back to the main list of vertical tabs.

Although we've got to find a different key, I wanted to re-roll it to move this along. Rolling the patch within /misc/ will cause it to break.

This should pass the bots I think. However we have to find an alternate solution.

I don't think that there should be * any * keystroke to move the user from the tab pane to the list o tabs. There are two reasons for this: 1. users won't know that the keystroke exists, 2. it may interfere with browser or assistive technology keymaps.

I'd be careful using a combination of custome and system colors, if users are using a high contrast, or custom, color scheme it may make the text unreadable.

Thanks for the feedback!

@mgifford
- I haven't thought of that. We might still use the enter key but look more precisely at the context where the event is triggered. I will give it some thought (and check the default behavior with collapsible fieldsets).

- Will roll the next patch correctly from the root directory, sorry.

@Everett
- I don't agree. We *do* need a keystroke to get back to the tab buttons. Otherwise you are stuck at the end of a tab pane. Further tabbing will bring you directly to the save button which is the desired behavior as we've already established (#67, #69).

- You are right with being careful mixing color schemes. Will give it some more thought.

Cheers,
Frank

@Frank

Being a keyboard only user I have to say that it would be completely expected behavior for me to have to shift-tab from the end of a tab pane back to the list of tabs on a web page. I cannot say what the expected behavior would be for a sighted keyboard only user.

How will you educate users about the keystroke to return to the list of tabs?

@Everett

The tabbing behavior is the same as with Drupal's usual collapsible fieldsets:

You can tab through all collapsed fieldsets and toggle the opening and closing of the fieldsets using the enter key. Actually, I found that out only by trial and error and I don't know whether this behavior is consistent across operating systems, browsers, and websites.

I would like to pose you the very same question: How do you know which keys to use on a specific website? I suppose it's dependent on the screen-reader? Or is there a kind of standard? What I learned about access keys (http://en.wikipedia.org/wiki/Access_key), there isn't much standardization yet regarding keyboard access to websites. I hope you will prove me wrong.

This patch addresses some of the above mentioned problems:

1. The enter key won't trigger the leaving of the tab pane when inside a textarea field.
2. The enter key now toggles correctly between a tab button and its corresponding tab pane (like the opening and closing of the collapsible fieldsets).
3. I did some refactoring to help better understand the code, mainly renaming of variables etc.

Cheers,
Frank

The last submitted patch failed testing.

OT: Sorry for my failing patches. Seems to be a bug of TortoiseCVS (http://drupal.org/node/113172).

EDIT:
Seems like the patch program requires the -p option like diff -u -p -r1.379 form.inc. Adding this manually to the patch files seems to work.

@Frank, Everett and others I follow on Twitter recently tweeted http://tinyurl.com/yaukt5y, a list of recommended keyboard shortcuts for use in website widgets. According to it, we should use the tab key to move focus from an opened tab to the first form field or link associated with that tab. Also, the Enter key should do nothing when focus is on the opened tab.

I know that answer doesn't make it easier on us, but at least it's clear.

@Cliff
Thanks for the link. That's what I've been looking for all the time. I haven't read all of the suggestions yet but I don't think they will solve the fundamental problem(s) we already have been talking about (#46, 58.2, 59 etc.), namely that this is kind of a two-dimensional navigation:

Flattening a two-dimensional navigation?

1. Each tab button gives us the choice to decide whether to proceed to the next tab button or to open the respective tab pane to make some changes.
2. And at the end of the tab pane there's the decision whether to proceed to the save button or to the next tab button.

Accessibilty vs. usability?

IMHO If we used only the tab key for proceeding through all of the tab buttons in linear order with no other key for making these two-dimensional decisions that wouldn't improve usability and accessibility at all, but to the contrary as it would force the user to tab through each and every input field in a one-dimensional way. That might be the familiar way for screen-reader users but IMHO would miss a chance to improve usability for other keyboard users.

Better off without vertical tabs?

In fact, in that case it would be better to use the usual collapsible fieldsets which would at least allow skipping fieldsets you don't want to make any changes to. It might very well be the case that improving the accessibility of vertical tabs for screen-reader users might mean to just provide and option to disable them in favor of the proven collapsible fieldsets.

I think these fundamental question have to be tackled first and a consensus has to be reached before we get lost in technical details about which colors to use (which is in danger of becoming a Bike shed discussion).

I hope these remarks don't come across too pessimistic but I feel we have reached kind of an impasse here.

Frank

EDIT:
Just stumbled across TabPanel widget design pattern in WAI-ARIA Best Practices. It seems to suggest using the arrow keys to move among the tabs.

Another useful resource: Code Talks: Keyboard navigable JS widgets

I do hope that we don't have to do the brutish disable javascript option to go back to a collapsible fieldset approach as visually the new layout is quite nice. Part of the problem is that we're in a transition period and that there aren't really good, understood standards available with ARIA yet. We're still using a Draft - W3C Working Draft 24 February 2009 - after all.

For keyboard users tabbing through the interface is still a core way to go through the site. Everyone should be able to use tab (and shift-tab) & enter to get through in a 1D format (forward & back) everything that they need. However using the arrow keys and implementing some of the suggestions in the WAR-ARIA best practices might be a nice addition for those who want a 2D experience (up/down left & right). If it works works well with this case then we should be good for those folks who don't know about the extra options.

It's encouraging though to see that in the W3C best practices that they do list some good examples of where this is going. Possibly when folks actually start adopting this next year these examples will be much more prevalent:
http://codetalks.org/source/widgets/tabpanel/tabpanel1.html

Expanding it a bit there's this more comprehensive list of possible changes that we might want to implement for D7:

• Tab : only the active tab is in the tab order.
• Left & Up (when tab in focus) : Show previous tab when focus is on tab buttons *
• Down (when tab in focus) : Show next tab tab when focus is on tab buttons *
• Right (when tab in focus) : Move to the main content of the vertical tabs *
• Ctrl+Shift+Pageup / Ctrl+Shift+Pagedown : same as left and right arrows but WILL cycle around the tab order
• Home : Show first tab when focus is on tab buttons
• End : Show last tab tab when focus is on tab buttons
• Ctrl+PgUp & Ctrl+Shift+Tab : Show next tab and restore focus to last control with focus or first control in tab if no previous focus
• Ctrl+PgDn & Ctrl+Tab : Show next tab and restore focus to last control with focus or first control in tab if no previous focus

It would be nice to have this available as an optional tab as they do in the codetalks example above. I edited the bullets above with the *.

As far as conflicts it would be useful to know if there are problems with any of the combinations above. There might be an issue with some folks, but I suspect that these are going to be better than say the Ctrl+letter combinations.

We should talk more about this though.

Mike

Some more unsorted comments:

One size to fit them all?

A "visually nice layout" is of minor or no importance to blind or visually impaired people. By aiming at what I would call "invisible accessibility" which works "under the hood" without impacting the visual design we might impose unnecessary constrains upon us. Most of those users either don't see the design at all or override it with a high contrast color scheme, larger font etc.

Arrows won't work

Arrow keys won't work as mentioned in #59.1 because they get in conflict with certain form elements. Imagine a tab pane which first input field is a set of radio buttons: Setting the focus on the radio buttons with the right arrow key, which behavior should be expected when pressing the left arrow key?

More feedback needed

We need far more feedback from real users than we can give among each other in this thread. I see some possible ways to go:

1. Move the patch into core and ask for feedback in the issue queue. After all, these changes don't affect the inner workings of Drupal and could easily be reverted by exchanging some JavaScript and CSS files
2. Make these changes into an Accessibility module - core optional or contributed. That way each user could decide whether to use these features or not
3. Make the settings configurable by the user, e.g. which keys to use for navigation. That way conflicts with some AT could be circumvented

Cheers,
Frank

I don't think we're going to be able to get rid of vertical tabs. Not even sure we'd get turning them off per user in core (although that's more likely). It doesn't address issues for non-users and people will be developing new modules with them next year to be used in all kinds of places.

I'm not the jQuery person, but I'm pretty sure that it's possible to set up events such that you need to be on the tabs in order for the arrows to work. You did something similar before before with "The enter key won't trigger the leaving of the tab pane when inside a textarea field." I've edited the list above though as it would be really counter intuitive to not be able to go right into pane from the tab. One would expect it to go to the right and not down. In anycase look at the edited comment #107 to see if this new list. Arrows work in the tabs but not with form elements, but that's easy enough to deal with (I think).

I can certainly set up a demo site with this and toss it around for a few keyboard only users to play with. In comment #93 you go through some of what this patch does. Can you outline it a bit more, particularly if you can line it up with any best practices here -> http://www.w3.org/TR/wai-aria-practices/#tabpanel

@Frank and Mike, I'm having trouble sorting out the details, but aren't the references saying that we should be using arrows to go from tab header to tab header and the tab key to go between a tab header and the contents of the tab panel?

If so, then the tab key insulates navigation within form elements from navigation between tab headers, so the problem raised in #59 isn't really a problem, right?

Would that be any easier to build?

Mike, in playing with the examples in the W3C page, I get confused. The only way (in Firefox, at least) that I could get from the last element in a tab panel to the next tab panel was to use Shift-Tab to back up to the current tab header and then use the right or down arrow to move one tab header over. (Hitting the tab key while on the last element in a tab panel took me out of the set of tab panels and to the next stop in the tab sequence.) When the tab panel included a set of radio buttons, I could not get past that to get back up to the tab headers.

:-|

Cliff

@Cliff

Default keyboard behavior - even without JavaScript

I think the tab key should be the primary key for keyboard navigation. After all, this is already the default behavior for websites even without any JavaScript. You can move between all elements which can get focus (usually links) within the taborder (which you can change with the tabindex attribute).

Pressing the enter key will follow/open that link.

Within forms the arrow keys will toggle between radio buttons, and the space bar will toggle checkboxes.

Can screen-reader users confirm this default behavior?

IMO any JavaScript should only enhance this expected behavior or make it possible in the first place as is the case with vertical tabs.

Documentation needed

I think we need a place for documenting some of the (preliminary) findings and results of this thread (and others), e.g. collecting links to important resources. This will also make it easier for others to join this important discussion.

Frank

@Frank

With JAWS 10 / FF 3.5 tab moves through focusable elements, arrows will move between radio options (if in "forms mode") and enter will activate a link / button.

@Everett

Thanks for the information. Some more questions for clarification:

1) What about the space bar, does it have any function?
2) How do the arrows behave outside of "forms mode"?

tia
Frank

Some more relevant resources

JAWS Keystrokes
http://www.freedomscientific.com/training/training-JAWS-keystrokes.htm

IAccessible2
I learned from the JAWS website that JAWS supports the IAccessible2 API. Will have a look whether this helps us with the issue at hand.

Just updating patch 102 so that it passes.

I've also applied it to the demo here - http://drupal7.dev.openconcept.ca/

Please sign up for an account if you want to test this.

Totally agreed on a space to discuss & document keyboard navigation. A wiki in the groups page would be a good start - http://groups.drupal.org/accessibility

Thanks again for all of the links on this subject. I've researched accessibility a lot in the last year but it's a pretty complex issue with lots of perspectives to consider. It also really doesn't help that the information isn't all kept up-to-date and there is no authoritative source other than the W3C.

To some degree this is just addressing the issue of the accessibility of the new vertical tabs feature, however it's also exploring other elements that will be important for other modules/features which extend D7.

Great idea! Done it:

Keyboard Navigation - Resources & Best Practices

http://groups.drupal.org/node/27992

Here's another screencast (SWF file), demonstrating the behavior of the latest patch. This time taken from /admin/structure/types/manage/page/edit to show the use of the enter key inside a textarea field.

@Frank

1) What about the space bar, does it have any function?

The space bar acts as a space bar in an editable field in forms mode. It also activates focused items that are actionable (links, buttons, etc.).

2) How do the arrows behave outside of "forms mode"?

Outside of forms mode the arrows read the page by line.

@Everett

Thanks for the information! At the moment I am tackling your still unsolved issue #89.

Marking the active tab for screen-readers

I hope to post a first patch in the next days.

(Example taken from documentation at Drupal 7 accessibility notes.)

Vertical tabs - the Microsoft way

Just stumbled across http://www.microsoft.com/Security_essentials/support.aspx?mkt=en-us#mainNav which also uses vertical tabs. Nice chance to test for usability and accessibility ;-)

This patch incorporates two features of mgifford's patch (#22) into my last patch (#102/114). It adds two invisible items for easier access with screen readers:

1. a H2 heading in front of the vertical tabs (see #364219: Navigation menus should be preceded by headings of the appropriate level (usually <h2>).)
2. a SPAN element to mark the active tab

However, this is still not perfect, mainly due to my changing the list from an unordered one (OL, with LI elements) to a definition list (DL, with DT and DD elements). The resulting HTML now looks like this which is quite jumbled:

It might be best to revert to the original markup as can be seen in #12 above.

I've installed this and it seems to work alright.

I'm not sure that the move to a definition list is going to provide much enhancement for the user, so I'd be fine with reverting back.

It's going to be a challenge enough to bring over a keyboard accessible interface.

I reverted to the unordered list and moved the invisible "active tab" hint into the link as requested by Everett in #25. The active tab will now be rendered as follows:

Please test.

I applied this here - http://drupal7.dev.openconcept.ca/

I still don't see a change in focus when tabbing (keyboard) through the vertical tabs (display). I just get that when I hit enter on a tab.

On the documentation side I'm not clear what we're testing for. The tab/enter works to get into the pane, but I need a list or a reference for what this should do and what we're testing for here.

@mgifford

Which browser do you use? The CSS pseudo class ":focus" doesn't work with every browser.

Okay, this might be completely off the mark, but have you guys read about the coding behind Yahoo's accessible tab interface?

Just askin'.

@Cliff
Thanks a lot for that hint! Looks very promising. Will read ASAP.

OT:
The great thing about YUI3 is that it looks a lot like jQuery ;-)

Frank, I was using FF 3.5.3 which supports focus as far as I'm aware.

Could you make a video demonstrating how it works? Maybe it's just something weird in my config, but would be nice to see both the focus elements but also how you're making this more of a 2D experience from the previous 1D (tab back & forth) reality.

I'd like to see what keys are actionionable.

Cliff, thanks for the link to the Yahoo example!

Here's a slightly modified patch (only some minor changes to the CSS) and a screen-cast showing its tabbing behavior:

1. The Tab/Shift tab key moves back and forth between the tab buttons or between the form elements when the focus is on the tab pane.
2. Tabbing beyond the last form element on any tab pane will bring you to the save button which can be triggered using the space-bar.
3. The Enter key toggles between entering and leaving a tab pane.
4. Within a form (tab pane) you can use the space-bar for toggling check-box states and the arrow-keys for changing radio-button states as usual.

AFAIK this behavior mimics the behavior of the usual collapsible fieldsets so keyboard navigation should be identical.

For rendering the different states of the tab buttons (hover, selected, focus...) there is heavy use of the "outline" CSS property (http://reference.sitepoint.com/css/outline) because this won't destroy any layout and should work across themes and color-schemes. Any of the CSS settings can easily be overridden on theme level.

I can navigate through it fine, but whipped clean my install and still couldn't see the focus properly in Firefox 3.5.3 on the Mac.

Focus works fine when tabbing to see the Skip Nav stuff though.

Took a screenshot here - sorry about the music in the background - http://screenr.com/n9H

Thanks for the screen-cast. Really strange. I suppose it's the Mac. I don't have one at hand but will do some research regarding CSS compatibility.

EDIT
Found an interesting links on CSS and accessibility: CSS for Accessibility

I added the pseudo class :active selector to the CSS for :focus. That improves the display in IE at least. As this is still work in progress I only post the modified CSS file instead of a patch.

@Frank - Ann McMeekin who did the CSS for Accessibility article back in 2007 has contributed to the Accessibility & Drupal 7 initiative. Has contributed some well thought out ideas here and helped move the discussion forward on some critical issues. EDITED COMMENT: The ideas are still relevant even though it's about 2 years old.

I couldn't track down how to change the colors properly even with firebug.

Sorry I haven't had the time to contribute as much here lately as I'd hoped to.

Mike, what is it about that article that you don't think is still relevant?

Sorry Ann. I misunderstood twitter comment from earlier in the day. Let me go edit that comment.

Here's some preliminary observations:

• In Firefox 3.5 the background color for the hover/active tab is very dark blue and it almost makes the tab name impossible to read. Whereas in Safari 4 it is a lighter blue that leaves the text legible. I don't yet know why the browsers interpret the CSS differently but I've attached screenshots that show the URL Path Settings tab hovered/active. (Tested on Mac)
• In VoiceOver screenreader on Mac, the tab-order of the vertical tabs still requires me to navigate through all the tabs before I get to the form elements of the selected tab. So when I click a tab link to change which tab is active, I have no indication that different form elements might be available later on the page and I still have to navigate past all the subsequent tabs to find the form elements. So basically it appears Safari/VoiceOver are not triggering the javascript events that this patch adds.

I'm just starting to test and get a handle on this important work. I'm so glad you all are tackling this. I hope this is helpful feedback. Let me know if there's other testing or input I can help with.

@Brandon

Many thanks for your most valuable feedback.

ad 1) That's because I am using "System Colors" for the background color but not yet for the foreground color (as discussed somewhere above in this thread). That still needs amending but it's already on my To-do-list.

ad 2) The whole patch requires a JavaScript enabled device as the additional functionality is only provided using JavaScript. The described behavior by you indicates that you can only access the tabs in DOM order. (Come to think of it, the DOM order of the vertical tabs is also changed by jQuery... )

How does your screen-reader behave with Drupal's usual collapsible fieldsets? The vertical tab behavior for keyboard navigation should mimic that.

tia
Frank

JFTR:

• Apple's VoiceOver screen-reader
• The Mac VoiceOver mailing-list
• Mac OS X - Introduction to Accessibility Overview

@#129

Theme related problem

The CSS of my patch does work with Garland but not with Seven yet. Will do some more testing.

Frank

EDIT
Seven comes with its own vertical-tabs.css file which overrides the one in /misc/.

Here's a quick hack to overcome the problem with the Seven theme. I just renamed the CSS file and made some minor modifications so that both CSS files for vertical tabs can live in peaceful coexistence. This surely needs some refinement. That's why I didn't role a proper patch but just attached the two modified theme files.

I also created an issue:
#611896: Seven's vertical-tabs.css interferes with accessibilty improvements

This slightly modified version of vertical-tabs.css should solve the problem mentioned in #135. It uses system colors for both foreground and background color of hover and focus state of elements:

Can you re-roll this into a single patch that can be applied to test this!

Here it is. This is a cumulative patch of all the modifications mentioned above. Note that this patch will also make changes to the Seven theme.

Tip: Use Dreditor for in-place review of these patches - it's a hell of a tool!

Ok, applies nicely. Like the new look of this patch. Much easier to see where the focus is.

With Tab, Tab-shift, arrow keys, & enter navigation through the site is much easier as a keyboard only user.

My only concern now is how use this? Should we have a question mark like with "More information about text formats ?" in the box above with say:

"More information about keyboard navigation ?"

Thanks for pushing through with this. Just need a few more folks to look at it and i think we'll be good to go.

Just a quick note to myself not to forget to adapt the RTL CSS file before this goes into production ;-)

Any update on this? What's left to do to move this issue forward?

Frank

I think we're just looking for another review.

It worked fine for me, I'd like a help link or something so that people get an explanation about how to navigate with the keyboard. However, that can come afterwards.

+1

@mgifford

I've been thinking about those usage hints but haven't come to a conclusion yet which might be the best and unobtrusive solution (see screenshot).

1) Shall the information be shown by default with the option to disable it?
2) Shall it be triggered somehow (mouse movement or absence thereof)?
3) Shall it only be shown on request? (But that leaves us with the very same problem, that the users must be aware of that feature in the first place...)

Is there a place anywhere else in Drupal which could serve as a model?

Frank

PS:
The patch does also work perfectly well with RTL languages, so no adaptation of vertical-tabs-rtl.css necessary.

@Frank Ralf - Damn good questions.

I'm going to mark this as RTBC. It would be good to get more feedback from keyboard only users, but I haven't succeeded in getting volunteers for this.

I think the question of how to inform folks about the keyboard navigation options probably should be something we think of after we get patch #141 into core.

I don't think that there are any other examples of this. I do like the idea of it being triggered by tabbing into the vertical tabs box, but this is setting a precedent and think it needs usability input.

Even undocumented this patch is an improvement for the current vertical tabs.

@Frank Ralf, @mgifford: With the instructions far from the action — way down at the right bottom, whereas the tabs are on the left — I suspect a lot of people will miss them. If this is the best we can do now, I would like to put out an idea for the next round of improvement.

In a lengthy discussion in the WebAIM archives on the topic of dropdown or flyout menus, one suggestion was that the item in the main menu should remain an active link to a new page that presents the contents of the flyout menu. (There are so many WebAIM discussions on this topic that I haven't been able to find the same one again.) People who cannot see or mouse into the flyout menu could then click the link in the corresponding main menu item to go to a page that presents them the same options they would have encountered in the flyout menu.

Would that approach work here? In other words, it would depend on having each vertical tab become a link at the same time it becomes active. The target of that link would be the first form element. Thus, we might be able to get screen readers to announce the alternative to continuing down the column of tabs. At the same time, people using keyboard access could use the tab key when they want to continue down the list of tabs or use the space bar (or whatever activates links in this context) when they want to move into the form elements.

If my hunch is right, that approach would make instructions unnecessary.

Thanks for the feedback, Cliff. The current behavior of the patch is described in #128. It is intended to mimic the behavior you described in your posting.

And you are right, providing instructions is a general issue and should be discussed more thoroughly in another thread. My screenshot was taken from my development machine and doesn't reflect the current patch's state (which comes without any instructions).

Cheers,
Frank

I've created a new discussion for the general question of informing users about available accessibility features: "Meta Accessibility" - How to Make Accessibility Features Known to the User

Frank

Great discussion post Frank! Definitely it's an area that we will need to address (though probably not in core).

For folks who don't have time to set up their own D7 install to test this patch I've got a simple version up here that's open for anyone to edit:

http://drupal7.dev.openconcept.ca/node/add/article

That should be up for the next week. Also a great way to take a look at accessibility enhancements in D7 core. There aren't too many customized patches there.

hmm, some weird behaviour there:

• tab to the second vertical tab (file attachments)
• press enter
• press tab again

expected behaviour: jumps to "browse" button or "attach" button
actual behaviour: jumps to "skip to main content" button at the top and tabbing more just continues down the page as it would when it was first loaded

Hi seutje,

Thanks for testing. The file attachment field behaves a bit strange in Firefox, as already noticed above (see #74 and #77). Is this the same behaviour you noticed? If yes, it's a browser specific problem and will have to be tackled separately from this patch.

Cheers,
Frank

as far as I can tell #74 and #77 are about the browse to file not opening when the field gets the focus by any other means than clicking

the weirdness I tried to explain is that when being in that field, pressing tab brings me to the very top of the page instead of the browse... button or the attach button as I would of expected, so perhaps make the focus go to the Browse... button when pressing enter on the vertical tab?

Ah, I think I understand now. I will look into this ASAP. Which browser do you use?

Frank

behaviour described above was experienced on FF 3.5.5 on vista & XP

using Safari 4.0.3 (vista) I couldn't manage to tab into the vertical tabs at all, it goes from the Tags field to the URL alias field to the Save button

using Chrome 3.0.195.33 (Vista), IE8 (vista) or IE6 (vista) I experienced no weird behaviour

Looks like this still needs work?

Well, yes, especially cross-browser testing. The patch relies mainly on jQuery's cross-browser capabilities so it might be difficult to discern, whether such issues stem from the patch or from browser incompatibilities in general.

I would be great to have kind of a matrix for all those browsers to compare the keyboard navigation with and without the patch.

Frank

@seutje

Unfortunately I don't have that many different browsers available for testing. Could you try whether this behavior only concerns file upload fields? That would be really helpful to isolate the problem.

tia
Frank

EDIT
I could reproduce the problem and will look into it. The correct behavior is that of the image upload field on http://drupal7.dev.openconcept.ca/node/add/article (FF 3.5, Win 2000):

* start tabbing on the title field
* pressing the tab key will bring you to the browse button of the image upload field
* pressing the space bar will open the file browse dialog
* the escape key will close the dialog box
* the next tab key press will bring you to the upload button which you can trigger by pressing the space bar

I suppose the jQuery code must behave differently for input fields of type "file" which seem to not be able to take the focus correctly.

@webchick - yes, sounds like we should do a matrix of some popular browsers and see how well the keyboard only enhancements work.

I think we're very close here, but need to investigate these issues.

@Frank Ralf: instead of explicitly forcing the focus to the next field, is there not a way we can emulate a keypress event for the tab key? (keycode 9) Because if we can do that, it should eliminate the FF weirdness, as it is only triggered by hitting enter on a tab (which forces focus on the next element, I assume). But I'd have to look into a reliable way to trigger a tab keypress, best thing I can come up with off the top of my (slightly intoxicated head) is something like

but I think that only triggers handlers associated with that event, so it won't work

EDIT:
the above won't work as it won't actually perform a tab but just fire all keypress handlers passing keycode 9

I tried a couple other things
throw a click event on the label -> nothing
throw a click event on the input -> nothing
throw a focus event on the label -> jumps to top
throw a focus event on the input -> jumps to top

I actually ended up trying a bunch of weird stuff, crashing my FF a good 27 times and I can't seem to find a way to make this work q.q

I'm actually starting to think that FF simply does not allow a script to set the focus to a file input

for instance, using this will effectively break tabbing to file fields without breaking tabbing to any other fields even though it does the same for all input fields, focus it without throwing a focus event (otherwise it'd be too much recursion)

why you ask? I have no clue, but if I had to guess I'd say they are intentionally blocking scripts from setting the focus to a file input fields by making the focus jump back to the window object

so logically, this will break all your input fields (xcept textareas coz they're not input elements but textarea elements)

same if u replace the ID with the ID of any file field...

I suppose the jQuery code must behave differently for input fields of type "file" which seem to not be able to take the focus correctly.

in one of the aforementioned examples I used this.focus() instead of $(this).focus(), thus using regular js focus method, so it's definitely not jQuery, but firefox (afaict right now)

I'm going to try poke some non-drupal js geniuses tomorrow and see if they can think of a way to sneak in a focus to a filefield

if this doesn't work out, would you consider it a good idea to leave the focus on the vertical tab and let the user manually tab to the contents of the tab or would this be pure weirdness for blind people? And how many people who need the accessibility stuff actually use firefox? a.k.a. would it be acceptable to ignore it? I'd say this is too much of a weirdness to ignore, even if 1/100000 users use firefox and use tab navigation, but I'm far from an expert on these matters... but I often use tab navigation when on my laptop without a proper mouse nearby

also, I currently have bigger concerns about the safari issue, as it doesn't even allow me to tab to the vertical tabs, I can only tab to their content...

I'm going to leave it at that for now as I'm sorta passing out, I apologise in advance for any mayor brainfarts in this post (I read it to myself a good 5 times though :P)

JFTR
Found this other thread regarding a similar issue #385732: Focus on first input element but still no clue how to overcome the problem.

This must be the crucial line in the patch:

Frank

I have created a simple test file for testing the keyboard navigation behavior of different form field types. The behavior of file upload fields seems to be indeed quite strange and not consistent across browsers.

That would indicate, that the problem at hand is not one of Drupal or jQuery but a more generic browser/JavaScript issue. (Which doesn't absolve us from finding a solution.)

Frank

I just want to put this in perspective. Right now nobody can use vertical tabs who doesn't have a mouse. With patch #141 it seems to be working in most instances. It might just be 95% of where it needs to be.

@seutje I'm using FF 3.5.5 for the Mac and haven't had it crash. Wonder if there's some strange windows vs Mac issue here as that's the only difference. There's a test case for FF here that's useful for keyboard navigation: http://www.mozilla.org/access/qa/win-webcontent-kbnav.html

With Safari you can tab between forms, but to tab between links you need to use Option-Tab or Shift-Option-Tab. The vertical tabs are links and not standard form elements. It seems to work fine if you use the silly Safari convention and add in the Option key. There might be a way to configure that to work without the Option key. God only knows what they are doing for this with Safari on Windows. It works for everything but the file upload for me. Don't think there are many Windows Safari users out there.

@Frank, thanks for the sample text file. I like how all of the form elements are so strongly highlighted on focus. I'd hoped something like that would work it's way into D7, but don't think that's practical at this point.

@mgifford I didn't mean that the patch crashed my FF, I was throwing weird stuff at it in an attempt to find a way to force focus on input type file, but there doesn't seem to be a way

@seutje - thanks for the clarification. In trying to seek some advice on this I pestered a few jQuery folks on twitter and got:

http://twitter.com/usejquery/status/6011601304

$('input[type=file]').trigger('click');

will only work for Safari and IE.Other browsers prevent non-human click events for security

So it is possible that this just isn't possible. If this is the case then we've got the best implementation we can derive in the last patch.

I might have found a solution using location.hash with the id of the file upload field instead of focus():

I haven't tested the code thoroughly yet so I simply attach the modified vertical-tabs.js file and an updated version of my test file to demonstrate the technique. Will roll it into a proper patch after more testing.

Cheers,
Frank

hmmm, this might actually work sorta kinda, in a way

I've set up a test page at http://jsbin.com/upasu and I'm getting the following behaviour:

When activating the link, the focus will sit in between the file field and the previous item, thus a tab will bring focus to the file field and a shift+tab will bring focus back to the item preceding the file field, so I'd suggest something like this:

that should trigger the focus on the first visible input field, causing the focus in FF to jump to the window object and then it should set the hash to that field's ID

do note that this will probably collide horribly with the overlay as it also uses those fragments, and we should probably utilize the same BBQ jquery plugin

@seutje

Many thanks for your input (and pointing me to jsbin.com which I haven't known before).

I added some more CSS to your demo page to better see where the focus is, see http://jsbin.com/unoza

AFAICT the behaviour is ok (at least with FF 3.5 on Windows 2000). Will have a closer look as soon as I find the time.

Cheers,
Frank

Yea, it isn't ideal, but I think it beats throwing focus to the window object

I guess that leaves us safari's unwillingness to focus non-inputs like the vertical tabs

@seutje

Focussing the vertical tabs is used by means of the tabindex attribute.

"Safari 1.2 does support tabindex (earlier versions do not), but the default setting is only partial support. To turn on full tabindex support, go the System Preferences keyboard shortcuts and check the Turn on full keyboard access check box."
http://www.webaim.org/techniques/keyboard/tabindex.php#browsersupport

I don't have Safari available. Could you try the above?

tia
Frank

This works for me on the Mac using Safari Version 4.0.4 (6531.21.10), Opera 10.10, FF 3.5.5 & Chrome 4.0.249.12

There were some display differences but the the biggest change was that Safari required me to tab once while the others I needed to tab twice.

Seems like we've found the solution!

I quickly rolled this into a patch for further testing. There's some additional code in it for development and testing purposes which has to be taken out before using this for production.

Frank

@Frank Ralf: oh oops, I did not know that *blush*

will try patch tomorrow