hello.

the new vertical tabs for d7 makes tab order unpredictable when navigated by a screen reader. one would first read "Menu settings
Not in menu" clicking it doesn't expand the fieldset as we're used to, but rather changes the form below the links. this is also true for Revision Information, comments settings, etc. so it took me some time to find out that clicking the link actually change the form below the links.

I wouldn't deem this chritical, because once one is used to this beahaviour it becomes easier to deal with the situation. the old way was certainly easier for us, screen readers users, because it took one click of the link to expand it. now you need to click the link, navigate through the remaining links to get to the form.

CommentFileSizeAuthor
#264 vertical-tabs_467296.264.patch6.1 KBFrank Ralf
#260 vertical-tabs_467296.260.patch5.97 KBFrank Ralf
#250 vertical-tabs_467296.250.patch6.39 KBmgifford
#247 vertical-tabs_467296.247.patch5.49 KBFrank Ralf
#239 screen-capture-20.png268.32 KBmgifford
#234 vertical-tabs_467296.234.patch5.41 KBFrank Ralf
#232 vertical-tabs_467296.232.patch5.39 KBFrank Ralf
#218 D7_Vertical_tabs_Screencast467296-217.zip132.13 KBFrank Ralf
#217 D7_Vertical_tabs_467296#217.zip132.13 KBFrank Ralf
#208 vertical-tabs_467296.208.patch5.7 KBmgifford
#205 vertical-tabs_467296.205.patch5.47 KBFrank Ralf
#201 vertical-tabs_467296.201.patch5.47 KBFrank Ralf
#202 vertical-tabs_467296.201.patch5.47 KBFrank Ralf
#198 vertical-tabs_467296.187.rev2_.patch6.46 KBFrank Ralf
#197 vertical-tabs_467296.187.rev_.patch6.46 KBFrank Ralf
#187 vertical-tabs_467296.186.patch6.47 KBmgifford
#179 vertical-tabs_467296.179.patch6.22 KBFrank Ralf
#174 vertical-tabs_467296.174.patch7.01 KBFrank Ralf
#167 focus_test_file_B.html_.txt2.66 KBFrank Ralf
#167 vertical-tabs.js_.txt4.81 KBFrank Ralf
#163 focus_test_file.html_.txt2.45 KBFrank Ralf
#146 Vertical_tabs_usage_hint.png50.01 KBFrank Ralf
#141 vertical-tabs_467296.141.patch7.97 KBFrank Ralf
#139 vertical-tabs.467296_139.zip696 bytesFrank Ralf
#138 467296_138_seven_vertical-tabs.zip958 bytesFrank Ralf
#135 vtab-firefox.gif48.88 KBbowersox
#135 vtab-safari.gif44.86 KBbowersox
#131 vertical-tabs.131.zip687 bytesFrank Ralf
#128 vertical-tabs_467296.128.patch5.83 KBFrank Ralf
#128 467296_D7_Vertical_tabs_Screencast3.zip125.74 KBFrank Ralf
#120 vertical-tabs_467296.120.patch6.87 KBFrank Ralf
#122 vertical-tabs_467296.122.patch5.86 KBFrank Ralf
#116 D7_Vertical_tabs_Screencast_2.zip159.26 KBFrank Ralf
#114 vertical-tabs_467296.113.patch6 KBmgifford
#102 vertical-tabs_467296.102.patch5.76 KBFrank Ralf
#97 vertical-tabs_467296.97_0.patch5.28 KBmgifford
#96 D7_Vertical_tabs.zip124.11 KBFrank Ralf
#95 vertical-tabs_467296.93.patch5.01 KBFrank Ralf
#93 vertical-tabs_467296.93.patch5.16 KBFrank Ralf
#81 tab_map.png26.18 KBCliff
#80 vertical_tabs.png25.81 KBCliff
#72 vertical-tabs_467296-67_ESC_key.js_2.patch5.25 KBmgifford
#67 vertical-tabs_467296-67_ESC_key.js_.patch5.13 KBFrank Ralf
#43 vertical-tabs_467296-43_keyboard_event.js_.patch4.21 KBFrank Ralf
#42 vertical-tabs_467296-40_definition_list.js_.patch3.82 KBFrank Ralf
#40 vertical-tabs_467296-definition_list.js_.patch0 bytesFrank Ralf
#39 vertical-tabs_467296-39.js_.patch732 bytesFrank Ralf
#22 form.inc-vertical-tab-a11y-3.patch1.79 KBmgifford
#15 form.inc-vertical-tab-a11y-2.patch732 bytesmgifford
#11 form.inc-vertical-tab-a11y.patch742 bytesmgifford
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webchick’s picture

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. :)

mohammed76’s picture

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.

mgifford’s picture

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.

Everett Zufelt’s picture

Title: improvements for vertical tabs » Accessibility improvements for vertical tabs
Component: javascript » node system
Priority: Minor » Normal

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

Owen Barton’s picture

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)?

bowersox’s picture

subscribing

Brigadier’s picture

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

mgifford’s picture

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:

  <h2 class="element-invisible">' . t('Advanced Administration tabs') . '</h2>

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:

  <span class="element-invisible"> (' . t('active tab') . ')</span>

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?

Garrett Albright’s picture

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

annmcmeekin’s picture

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.

mgifford’s picture

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:

<h2 class="element-invisible">' . t('Administration Tabs') . '</h2>

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:

this.item.after('<span class="element-invisible"> (' . Drupal.t('active tab') . ')</span>');

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:

<li class="vertical-tab-button selected">
  <a href="#"> 
    <strong>Book outline</strong>
    <small class="summary">Not in book</small>
  </a>
</li>

I'm thinking it should look like:

<li class="vertical-tab-button selected">
  <span class="element-invisible">Active tab</span>
  <a href="#edit-book"> 
    <strong>Book outline</strong>
    <small class="summary">Not in book</small>
  </a>
</li>

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

Mike

rvilar’s picture

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:

<li class="vertical-tab-button selected">
  <span class="element-invisible">Active tab</span>
  <a href="#edit-book">
    <strong>Book outline</strong>
    <span class="summary">Not in book</span>
  </a>
</li>

Ramon

Everett Zufelt’s picture

Status: Active » Needs review

@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.

Everett Zufelt’s picture

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.

mgifford’s picture

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:

mike-gifford-admins-macbook-pro:drupal-cvs mike$ grep -ir '<small>' *
includes/locale.inc:      array('data' => check_plain(truncate_utf8($string['source'], 150, FALSE, TRUE)) . '<br /><small>' . $string['location'] . '</small>'),
modules/node/content_types.inc:  $output .= ' <small> (Machine name: ' . check_plain($type->type) . ')</small>';
modules/upload/upload.module:      $form['files'][$key]['description'] = array('#type' => 'textfield', '#default_value' => !empty($file->description) ? $file->description : $file->filename, '#maxlength' => 256, '#description' => '<small>' . file_create_url($file->uri) . '</small>');

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

mike-gifford-admins-macbook-pro:drupal-cvs mike$ grep -ir FieldsetSummaries *
modules/book/book.js:Drupal.behaviors.bookFieldsetSummaries = {
modules/comment/comment-node-form.js:Drupal.behaviors.commentFieldsetSummaries = {
modules/menu/menu.js:Drupal.behaviors.menuFieldsetSummaries = {
modules/node/node.js:Drupal.behaviors.nodeFieldsetSummaries = {
modules/path/path.js:Drupal.behaviors.pathFieldsetSummaries = {
modules/upload/upload.js:Drupal.behaviors.uploadFieldsetSummaries = {

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

Mike

mgifford’s picture

Issue tags: +vertical tabs

adding tag for vertical tabs

mgifford’s picture

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.

Everett Zufelt’s picture

@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.

kat3_drx’s picture

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.

mgifford’s picture

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

attiks’s picture

mgifford’s picture

with some ajax added for displaying active tab

kat3_drx’s picture

@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. :)

mgifford’s picture

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?

Everett Zufelt’s picture

Status: Needs review » Needs work

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.

Cliff’s picture

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?

kat3_drx’s picture

@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.

mgifford’s picture

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.

Frank Ralf’s picture

@#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

Everett Zufelt’s picture

@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.

Frank Ralf’s picture

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

Everett Zufelt’s picture

@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.

Frank Ralf’s picture

One question:

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

kat3_drx’s picture

@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?

mgifford’s picture

@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!

Frank Ralf’s picture

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:

<ul>
  <li class="vertical-tab-button last selected">
    <a href="#">
      <strong>Publishing options</strong>
      <small class="summary">Published, Promoted to front page</small>
    </a>
  </li>
</ul>

we could use definition list like so:

<dl>
  <dt class="vertical-tab-button last selected">
    Publishing options
  </dt>
  <dd class="summary">
    Published, Promoted to front page
  </dd>
</dl>

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

mgifford’s picture

@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

Frank Ralf’s picture

@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.

Frank Ralf’s picture

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/)

Frank Ralf’s picture

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.

mgifford’s picture

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

Frank Ralf’s picture

Oops, sorry. Here it comes again.

Frank Ralf’s picture

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.)

Cliff’s picture

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!

Cliff’s picture

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.)

Frank Ralf’s picture

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?

Frank Ralf’s picture

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...

Everett Zufelt’s picture

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

mgifford’s picture

@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.

Cliff’s picture

@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?

Frank Ralf’s picture

@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

Frank Ralf’s picture

@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

Cliff’s picture

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

mohammed76’s picture

hello,

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

attiks’s picture

@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

Cliff’s picture

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?

Frank Ralf’s picture

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

attiks’s picture

@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.

Cliff’s picture

@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.

Frank Ralf’s picture

@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.

Everett Zufelt’s picture

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?

Frank Ralf’s picture

@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...):

div.vertical-tabs dl.vertical-tabs-list dt a:focus {
  background-color: fuchsia;
  position: relative;
  z-index: 5;
}

div.vertical-tabs dl.vertical-tabs-list dt a:hover {
  background-color: yellow;
  text-decoration: none;
}

Cheers,
Frank

Everett Zufelt’s picture

@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.

Frank Ralf’s picture

@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?

Everett Zufelt’s picture

@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

Frank Ralf’s picture

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.
kat3_drx’s picture

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. ^^

Everett Zufelt’s picture

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?

mgifford’s picture

Status: Needs work » Needs review

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.

Status: Needs review » Needs work

The last submitted patch failed testing.

mgifford’s picture

Status: Needs work » Needs review
FileSize
5.25 KB

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.

Cliff’s picture

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.

Frank Ralf’s picture

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

mgifford’s picture

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.

Everett Zufelt’s picture

@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.

Frank Ralf’s picture

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).

webchick’s picture

Looks like this still needs more discussion...

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

Everett Zufelt’s picture

@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.

Cliff’s picture

FileSize
25.81 KB

@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.

Cliff’s picture

FileSize
26.18 KB

@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.

seutje’s picture

Subscribe

Frank Ralf’s picture

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

RobLoach’s picture

Hitting the virtual subscribe button!

Frank Ralf’s picture

@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).

Cliff’s picture

@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.)

;-)

Cliff’s picture

Oops. Saved twice! (Working too late.)

Frank Ralf’s picture

@#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

Everett Zufelt’s picture

@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.

Status: Needs review » Needs work

The last submitted patch failed testing.

Frank Ralf’s picture

@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??

mgifford’s picture

Status: Needs work » Needs review

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

Frank Ralf’s picture

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.

Status: Needs review » Needs work

The last submitted patch failed testing.

Frank Ralf’s picture

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

Frank Ralf’s picture

FileSize
124.11 KB

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

mgifford’s picture

Status: Needs work » Needs review
FileSize
5.28 KB

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.

Everett Zufelt’s picture

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.

Frank Ralf’s picture

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

Everett Zufelt’s picture

@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?

Frank Ralf’s picture

@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.

Frank Ralf’s picture

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

Status: Needs review » Needs work

The last submitted patch failed testing.

Frank Ralf’s picture

Status: Needs review » Needs work

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.

Cliff’s picture

@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.

Frank Ralf’s picture

Status: Needs review » Needs work

@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 http://www.w3.org/TR/wai-aria-practices/#tabpanel">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

mgifford’s picture

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

Frank Ralf’s picture

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

mgifford’s picture

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

Cliff’s picture

@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

Frank Ralf’s picture

@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

Everett Zufelt’s picture

@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.

Frank Ralf’s picture

@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.

mgifford’s picture

Status: Needs work » Needs review
FileSize
6 KB

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.

Frank Ralf’s picture

Great idea! Done it:

Keyboard Navigation - Resources & Best Practices

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

Frank Ralf’s picture

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.

Everett Zufelt’s picture

Status: Needs work » Needs review

@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.

Frank Ralf’s picture

@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.

l(t('Read more...<span class="element-invisible"> about %title</span>', array('%title' => $node->title)), 'node/' . $node->nid, array('html' => TRUE));

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

Frank Ralf’s picture

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 ;-)

Frank Ralf’s picture

Status: Needs work » Needs review
FileSize
6.87 KB

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:

<dt class="vertical-tab-button selected" tabindex="-1">
  <a href="#">
    <strong>Comment settings</strong>
    <dd class="summary">Closed</dd>
  </a>
  <span id="active-vertical-tab" class="element-invisible">(active tab)</span>
</dt>

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

mgifford’s picture

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.

Frank Ralf’s picture

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:

<li class="vertical-tab-button selected" tabindex="-1">
  <a href="#">
    <strong>URL path settings</strong>
    <span class="summary">No alias</span>
    <span id="active-vertical-tab" class="element-invisible">(active tab)</span>
  </a>
</li>

Please test.

mgifford’s picture

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.

Frank Ralf’s picture

@mgifford

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

Cliff’s picture

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

Just askin'.

Frank Ralf’s picture

@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 ;-)

mgifford’s picture

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!

Frank Ralf’s picture

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.

mgifford’s picture

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

Frank Ralf’s picture

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

Frank Ralf’s picture

FileSize
687 bytes

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.

mgifford’s picture

@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.

annmcmeekin’s picture

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?

mgifford’s picture

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

bowersox’s picture

FileSize
44.86 KB
48.88 KB

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.

Frank Ralf’s picture

@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:

Frank Ralf’s picture

@#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/.

Frank Ralf’s picture

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

Frank Ralf’s picture

FileSize
696 bytes

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:

background-color: Highlight;
color: HighlightText;
mgifford’s picture

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

Frank Ralf’s picture

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!

mgifford’s picture

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.

Frank Ralf’s picture

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

Frank Ralf’s picture

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

Frank

mgifford’s picture

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

Frank Ralf’s picture

FileSize
50.01 KB

@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.

mgifford’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +D7UX usability

@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.

Cliff’s picture

@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.

Frank Ralf’s picture

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

Frank Ralf’s picture

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

mgifford’s picture

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.

seutje’s picture

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

Frank Ralf’s picture

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

seutje’s picture

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?

Frank Ralf’s picture

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

Frank

seutje’s picture

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

webchick’s picture

Status: Reviewed & tested by the community » Needs work

Looks like this still needs work?

Frank Ralf’s picture

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

Frank Ralf’s picture

@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.

mgifford’s picture

@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.

seutje’s picture

@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

foo = $.Event('keypress');
foo.keyCode = 9;
$('this').trigger(e):

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)

$('input').bind('focus', function(e) {
this.focus();
});

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)

$('input').bind('focus', function(e) {
$('#edit-upload')[0].focus();
});

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)

Frank Ralf’s picture

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:

// Set focus on the first input field of the visible fieldset/tab pane
$("fieldset.vertical-tabs-pane :input:visible:enabled:first").focus();

Frank

Frank Ralf’s picture

FileSize
2.45 KB

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

mgifford’s picture

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.

seutje’s picture

@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

mgifford’s picture

@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.

Frank Ralf’s picture

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

location.hash = "#edit-upload";

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

seutje’s picture

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:

      location.hash = "#" + $("fieldset.vertical-tabs-pane :input:visible:enabled:first").focus().attr('id');

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

Frank Ralf’s picture

@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

seutje’s picture

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

Frank Ralf’s picture

@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

mgifford’s picture

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!

Frank Ralf’s picture

Frank Ralf’s picture

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

seutje’s picture

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

will try patch tomorrow

mgifford’s picture

The patch applied well, but on the Mac I couldn't replicate the results that I'd had in http://jsbin.com/unoza

I wasn't able to get it to pull up the browser's file manager to load the file.

It was like I could just get half way there. Was an improvement, but not a working solution.

I liked the red backgrounds for debugging purposes.

Frank Ralf’s picture

@seutje

No need for blushing - I didn't know that either and found out only by some googling after reading your comment ;-)

mgifford’s picture

I would like to suggest now that we bring the patch in #141 to be RTBC. We've spent a great deal of time looking for a solution for the file upload field and haven't nailed the solution.

Keyboard navigation needs to be in core.

@Frank, do you have any new code to test that might address this one last issue today?

Frank Ralf’s picture

Status: Needs review » Needs work
FileSize
6.22 KB

@Mike

This is basically the patch from #174 but without the additional CSS for debugging and also without the modifications to the Seven theme. This issue should better be addressed separately (#611896: Seven's vertical-tabs.css interferes with accessibilty improvements).

Keyboard navigation for file upload fields doesn't work as smoothly as for other fields:

1) The viewport might change but is still on the vertical tabs in general.
2) You have to tab twice to get to the "Browse" button for making the Enter key work to bring you back to the vertical tab buttons.

But IMO these are minor issues compared to the one which got us looking at file fields in the first place, namely totally loosing focus on file upload fields with keyboard navigation.

Cheers,
Frank

mgifford’s picture

Status: Needs work » Needs review

setting this as needs review

Frank Ralf’s picture

Status: Needs work » Needs review

The seemingly missing highlighting stems from the problem with the Seven theme mentioned above (#137, #138), namely the Seven theme overriding our CSS with its own. This issue can easily be amended by renaming one of the involved CSS files. See #611896: Seven's vertical-tabs.css interferes with accessibilty improvements for this problem in the Seven issue queue.

If you test the patch with any other theme (e.g. Garland) you should see that the highlighting works.

Frank

mgifford’s picture

Status: Needs review » Reviewed & tested by the community

Ok, it's good to hear it's an issue with Seven (I'll comment on that as well).

This patch does extend the accessibility of Drupal 7 for keyboard only users and I am quite happy to recommend it to core.

Rich Caloggero’s picture

First, let me post a disclaimer: I'm not a drupal developer, so I cannot offer patches. I am a blind web developer, so I do have a suggestion on how to make tabbed UIs a bit more screen reader friendly.

1. Use headings at the top of each tab's content panel. If you don't want these headings vissible, use the .screenReaderOnly class (drupal has another name for this which I'm forgetting at present). See the code below for the CSS for this.

2. Use liveregion markup to cause the screen reader to speak all changes to the tablist (the list of links which you click to activate the various content panels).

3. When a new tab opens, add some text to the content of the link you click to activate it showing that its active. Tag this with the screenReaderOnly class (see above). Be sure to remove all other active tab markers previously set.

The effect of this is that when the new tab is shown, the text of the link which was clicked to activate it changes to reflect the fact that it is now active. Since the list of tabs has the aria-live="assertive" attribute set, then the change will be spoken.
See section 5.2 of the aria Best Practices guide:
http://www.w3.org/WAI/PF/aria-practices/

*** Note: the liveregion markup works only in recent versions of screen readers such as Jaws, Window-eyes, and Orca, Older versions will happily ignore the attribute(s) so the experience gracefully degrades.

I've posted an example of this which uses jQuery UI's tabs module. Have no idea how one would implement this in Drupal. jQuery-ui is nice because it fires an event when a new tab is shown, making it very easy to add this functionality.

<html>
<head>
<title>
Tabs Test
</title>

<style>
.screenReaderOnly {
position: absolute;
height: 0;
overflow: hidden;
}
</style>

<link href="jQuery-ui-css/base/jquery-ui.css" rel="stylesheet" type="text/css"/>

<script type="text/javascript" src="jQuery.min.js"></script>
<script type="text/javascript" src="jQuery-ui.min.js"></script>
<script>
$(document).ready(function() {
$("#tabs").tabs ({
show: function (e, ui) {
$("#activeTab").remove ();

$(ui.tab).append (
'<span id="activeTab" class="screenReaderOnly"> (active)</span>'
); // append
} // show
}); // tabs

});     // document ready

alert ("loaded");

</script>
</head>
<body>
	<h1>Test</h1>

<div id="tabs">
<ul aria-live="assertive">
<li><a href="#t1">Fruits</a></li>
<li><a href="#t2">Veggies</a></li>
</ul>

<div id="t1">
<ul>
<li>Apple</li>
<li>Bannanna</li>
<li>Pear</li>
<li>Watermellon</li>
</ul>
</div>

<div id="t2">
<ul>
<li>Carrot</li>
<li>Squash</li>
<li>Potato</li>
<li>Broccoli</li>
</ul>
</div>

</div>

<div id="output" aria-live="assertive" tabindex="0" title="Output">
</div>

</body>
</html>
seutje’s picture

Thank you very much for this valuable suggestion and documentation, it seems like a small addition we can easily slide in before getting this committed, but it also seems reasonable to do this as a follow-up, either way, I really think we should implement this

the screenReaderOnly class u mention is the element-invisible class I think

is there a reason you are going with a span instead of a heading?

also, your example uses a single output div, whose content changes as another tab is clicked, as far as I know, this isn't how vertical tabs work, as they just hide the content of inactive tabs, so I'm not sure if your example is applicable as-is, but I'm sure we can do something in that direction

also, may I ask if you have tried the patch in #179 comparison to current state in HEAD? I think you can still test it here without having to apply the patch yourself (can you confirm this is the right version, Frank?)

Frank Ralf’s picture

@seutje

At first glance http://drupal7.dev.openconcept.ca/node/add/article doesn't seem to have any of the patches applied. The site was set up by mgifford.

mgifford’s picture

Status: Reviewed & tested by the community » Needs work

@Frank - Yes, sorry I've been using that to test a number of patches. Must have had to clear the file system at some point. It's there now.

I'm putting this back to needs work so we review some of these changes. I modified this line in the existing patch:

+      var tablist = $('<ul class="vertical-tabs-list"></ul>');
</code?

to include aria-live="assertive" in http://drupal7.dev.openconcept.ca/node/add/article 

<code>
+      var tablist = $('<ul class="vertical-tabs-list" aria-live="assertive"></ul>');

@RichCaloggero can you review the sandbox above and get back to us? Thanks for suggestions.

mgifford’s picture

Status: Needs work » Needs review
FileSize
6.47 KB

I wanted to try to validate the aria-live suggestion that @RichCaloggero provided but it's being produced by javascript so the validators (well ok http://validator.w3.org is the one I used) rolls past it.

I've added it into this patch though for folks to review. It's just like the one that was RTBC'd but includes the aria-live for screen readers.

mgifford’s picture

Status: Needs review » Reviewed & tested by the community

I haven't found someone else to review the aria-live addition that I added in the patch above so am setting it back to RTBC on issue #179.

#187 is a pretty trivial change, but we needed more feedback on it.

Status: Reviewed & tested by the community » Needs review

Re-test of vertical-tabs_467296.186.patch from comment #187 was requested by webchick.

mgifford’s picture

Since you retested the patch from #187 I thought I'd add that the only difference between that one and #179 is:
aria-live="assertive"

This should give better performance for screen readers but I wasn't able to get user feedback to confirm this.

I'd be happy with either patch getting into core and they are both still passing the bot. I was just trying to be more conservative.

mgifford’s picture

Status: Needs review » Reviewed & tested by the community

setting it back to rtbc.

webchick’s picture

Status: Reviewed & tested by the community » Needs work

Wow. Excellent team work on this issue, folks.

I ran through some quick tests and didn't see any regressions for sighted users. It sounds like there might be some clean-up work required for this patch once it gets broader testing, but committing this should get those bugs fleshed out quicker than leaving this patch here in the issue queue.

Just some minor clean-up work and this should be good to go. This is a review against the version with ARIA support:

+++ misc/vertical-tabs.css	8 Dec 2009 21:28:56 -0000
@@ -40,27 +41,38 @@ div.vertical-tabs ul.vertical-tabs-list 
+  background-color: Highlight;
+  color: HighlightText;
...
+  background-color: Highlight;
+  color: HighlightText;
...
+  background-color: White;

I believe these should all be in lowercase. Or at least I don't remember ever seeing Proper Cased colours in core before.

+++ misc/vertical-tabs.js	8 Dec 2009 21:28:56 -0000
@@ -17,31 +17,34 @@ Drupal.behaviors.verticalTabs = {
+      var tabfocus;  // Refactoring names - too much "focus"

We don't need that comment there. Also, we don't run wordstogetherlikethis. Please name the variable tab_focus.

+++ misc/vertical-tabs.js	8 Dec 2009 21:28:56 -0000
@@ -17,31 +17,34 @@ Drupal.behaviors.verticalTabs = {
+      var tablist = $('<ul class="vertical-tabs-list" aria-live="assertive"></ul>');

same. tab_list

+++ misc/vertical-tabs.js	8 Dec 2009 21:28:56 -0000
@@ -17,31 +17,34 @@ Drupal.behaviors.verticalTabs = {
+        var vtab = new Drupal.verticalTab({

vertical_tab

+++ misc/vertical-tabs.js	8 Dec 2009 21:28:56 -0000
@@ -63,6 +66,28 @@ Drupal.verticalTab = function (settings)
+  // Pressing the Enter key will open the tab pane
...
+      // Set focus on the first input field of the visible fieldset/tab pane
...
+  // Pressing the Enter key lets you leave the tab again
...
+    // Enter key should not trigger inside <textarea> to allow for multi-line entries
...
+      // Set focus on the selected tab button again

Comments should end in a period.

+++ misc/vertical-tabs.js	8 Dec 2009 21:28:56 -0000
@@ -63,6 +66,28 @@ Drupal.verticalTab = function (settings)
+      location.hash = "#edit-upload";

I don't quite parse JS, but it looks like this is defaulting to the upload module vertical tab? If so, we no longer ship D7 with upload module. This should probably default to something else (or better, the first vertical tab in the list).

If this means something else entirely, then ignore me. ;)

This review is powered by Dreditor.

RobLoach’s picture

Status: Needs work » Reviewed & tested by the community
-  return '<div class="vertical-tabs-panes">' . $element['#children'] . '</div>';
+  $output = '<h2 class="element-invisible">' . t('Vertical Tabs') . '</h2>';
+  $output .= '<div class="vertical-tabs-panes">' . $element['#children'] . '</div>';
+  return $output;
 }

Instead of just "Vertical Tabs", could we use that as a fallback to $element['#title']? If you disable CSS in your browser, you end with with "Vertical Tabs" as headings for all the tabs, which has absolutely no meaning to the user. Maybe something like:

-  return '<div class="vertical-tabs-panes">' . $element['#children'] . '</div>';
+  $title = isset($element['#title']) ? $element['#title'] : t('Vertical Tabs');
+  $output = '<h2 class="element-invisible">' . $title . '</h2>';
+  $output .= '<div class="vertical-tabs-panes">' . $element['#children'] . '</div>';
+  return $output;
 }

.... or perform that processing and inject the default t('Vertical Tabs') #title in the vertical tabs Form API element processing? Forgive me if this has been discussed before, I wasn't quite looking forward to reading through #190 comments.

RobLoach’s picture

Status: Reviewed & tested by the community » Needs work

Whoops, sorry for the status cross posting.

Frank Ralf’s picture

@webchick

Thanks for the feedback. Will amend the patch ASAP.

Frank

Frank Ralf’s picture

I just applied the suggested improvements by webchick to the patch, not tested yet.

The last comment regarding the Upload module still needs to be investigated.
location.hash = "#edit-upload"; was added because of the problem setting focus to an upload field when it's the first field on a tab (see above).

Frank

Frank Ralf’s picture

I just applied the suggested improvements by webchick to the patch, not tested yet.

The last comment regarding the Upload module still needs to be investigated.
location.hash = "#edit-upload"; was added because of the problem setting focus to an upload field when it's the first field on a tab (see above).

Frank

Frank Ralf’s picture

Uploaded the patch again, seems to be broken.

Frank

mgifford’s picture

Status: Needs work » Needs review

setting to needs review.

mgifford’s picture

Status: Needs review » Reviewed & tested by the community

I've added this patch to one of my sandboxes and tested it for keyboard navigation. Seems to still work well.

I believe that the outstanding concerns about the minor code cleanup have been done so I'm setting this back to RTBC.

Frank Ralf’s picture

As I had some problems applying the patch from #198 to my most recent installation of Drupal 7 I recreated the patch. This patch only contains the modifications to /misc/vertical-tabs.css and /misc/vertical-tabs.js. I incorporated webchick's suggestions from #192.

@mgifford
I didn't include your modifications to /includes/form.inc as it seems to me that the respective function has changed considerably (line 2709 ff.):

// The JavaScript stores the currently selected tab in this hidden
  // field so that the active tab can be restored the next time the
  // form is rendered, e.g. on preview pages or when form validation
  // fails.
  $name = implode('__', $element['#parents']);
  if (isset($form_state['values'][$name . '__active_tab'])) {
    $element['#default_tab'] = $form_state['values'][$name . '__active_tab'];
  }
  $element[$name . '__active_tab'] = array(
    '#type' => 'hidden',
    '#default_value' => $element['#default_tab'],
    '#attributes' => array('class' => array('vertical-tabs-active-tab')),
  );

Your addition from #186 is also missing.

And the problem of #611896: Seven's vertical-tabs.css interferes with accessibilty improvements still persists so you better test the patch with Garland to see the whole effect.

Frank

Frank Ralf’s picture

Accidental click... sorry.

Frank Ralf’s picture

Status: Reviewed & tested by the community » Needs review

changed status

Status: Needs review » Needs work

The last submitted patch, vertical-tabs_467296.201.patch, failed testing.

Frank Ralf’s picture

Another try...

Frank Ralf’s picture

Status: Needs work » Needs review

Changing status to "needs review".

Status: Needs review » Needs work

The last submitted patch, vertical-tabs_467296.205.patch, failed testing.

mgifford’s picture

Status: Needs work » Needs review
FileSize
5.7 KB

resubmitting for bots

mgifford’s picture

Status: Needs review » Reviewed & tested by the community

I tested this and it works. Thanks for the feedback on this everyone!

Everett Zufelt’s picture

Status: Reviewed & tested by the community » Needs review

Wow, a lot of great work has gone into this since I was last involved several months ago. Great work.

A few questions:

1. Can someone please explain all of the changes in one comment?

1.1 Has visual appearance changed?

1.2 How has expected behavior changed for keyboard only users?

1.3 How has expected behavior changed for screen-reader users (if this varies by screen-reader please let me know)?

2. Are there any concerns (visibility of focus / contrast) for low vision users?

Thanks

Frank Ralf’s picture

@Everett

1.1 The patch uses system colors and CSS outline for visual highlighting of the focused tab. Both settings are theme independent and don't change the layout of the page (as using CSS borders would do for example). Unfortunately both properties are overridden by the Seven theme's own vertical-tabs.css (see #611896: Seven's vertical-tabs.css interferes with accessibilty improvements).

1.2 The tab panes can be accessed by keyboard only users from the tab buttons without the patch, but there's no way back. With the patch you can tab back and forth between the tab buttons. Pressing the enter key brings you to the respective tab pane and back again to the tab buttons.

1.3 The patch only relies on the tab and enter key for navigation which should be accessible to screen readers (but I don't have any firsthand experience).

2. No, on the contrary. Using system colors (which can be set by the user independent from any application) and using outline actually enhances the visibility of focus and contrast. The effect can best be seen when using Garland as admin theme due to the mentioned problem with the Seven theme. There also is a screencast further up in this thread.

hth
Frank

Everett Zufelt’s picture

Issue tags: +Needs usability review

tagging

Everett Zufelt’s picture

1.1 The patch uses system colors and CSS outline for visual highlighting of the focused tab. Both settings are theme independent and don't change the layout
of the page (as using CSS borders would do for example).

Tagged issue as needs usability review particularly to get feedback on using system colours here. Are these colours used only on focus, or on active / hover as well?

Can themes override the colours we have chosen here?

1.2 The tab panes can be accessed by keyboard only users from the tab buttons without the patch, but there's no way back. With the patch you can tab back
and forth between the tab buttons. Pressing the enter key brings you to the respective tab pane and back again to the tab buttons.

I just tried an unpatched install of D7 with a screen-reader with virtual cursor disabled (which should provide me similar functionality to a keyboard only user). I was able to tab through the tab buttons through the tab pane and out of the tab pane back into the document. I was able to reverse this without an issue. I was able to press enter on a tab button to switch active panes, to tab to the pane, tab back and press enter on another button to switch active panes again without a problem.

Can you let me know if this is behavior consistent with what you've experienced on an unpatched system? I'm not sure what I am supposed to expect for changed behavior here.

With the patch:

When in the strip of tab buttons what is the expected behavior of: tab, shift + tab, enter?
When in the tab pane what is the expected behavior of: tab, shift + tab, enter?

Just having a hard time identifying the problem that we are trying to solve for keyboard only users and exactly how the patch is supposed to change the expected behavior. I definitely think the patch needs a peer review before being ready to be RTBC

Bojhan’s picture

Just reviewed this it seemed to create no visual appearance changes, so that's good to go from my part. Tried to figure out what has been made more accessible, but couldn't really figure that out either - Everett said it works, so I am leaving it for others to put RTBC.

There needs to be a visual cue that a tab is on:focus the common thing would be to underline the link. Probably worthy for a new issue though

Everett Zufelt’s picture

. Realized that Bojhan was testing on Seven, not Garland. We already have an issue (I just marked critical) for Seven's implementation of vertical-tabs.css that prevents us from being able to show the focused tab button.

2. Still needs usability review for colours on focused tabs in Garland.

3. Tested the aria-live region for changing status of tab buttons "(active tab)". Tested with JAWS 11 and NVDA 2009.1 (both with FF 3.6). JAWS announces inconsistently NVDA doesn't announce at all, can be fixed after patch is committed.

Bojhan’s picture

Status: Needs review » Reviewed & tested by the community

2. Is fine.

Frank Ralf’s picture

@Everett

@2.
The active tab button is rendered with a white background in Garland which is low contrast to the light blue of the other tab buttons. The patch enhances that with a thin solid outline in the system color "HighlightText".

The tab button with the keyboard focus will get a thicker dotted outline and the background color switches to the system color "Highlight".

If the keyboard focus is on the active tab button the dotted outline changes to a solid one.

In addition to that the patch also uses the same color scheme for highlighting the tab button over which the mouse hovers but without the outline to make it distinguishable from the keyboard focus.

I added a screencast which shows the patch in action with Garland.

Frank

Frank Ralf’s picture

Something's wrong with the attachment. Try again.

Bojhan’s picture

@Frank No way, we are not doing that. That looks very bad.

Frank Ralf’s picture

@Bojhan

Could you please be a bit more specific (and contructive)?

tia
Frank

Bojhan’s picture

@Frank Well I am not sure what more I can say, look at this from a designers perspective. Would this be favourable? Does this look good? I am very inclined to say no, it took us a lot of time designing vertical tabs - and this introduces a new visual element, where there is actually already a visual element (the color of the link).

Everett Zufelt’s picture

I would say that we absolutely need to get this patch into D7. Some things that I think are necessary to get us there.

1. A concise list of any ways in which vertical tabs are unusable (e.g. tab focus not perceivable) by persons with disabilities. If this can be clearly identified we can likely mark this issue as Critical.

2. A detailed description of expected keyboard behavior in the current patch, so that it can be QA tested. Without expected behavior we cannot test, without testing we cannot commit.

3. A way to visibly identify the difference between a) inactive tab button b) active tab button, c) tab button with focus, that can pass usability testing. Any ways in which Seven's vertical-tabs.css blocks this isn't a big issue, as there is already a Critical issue open about that.

Frank Ralf’s picture

@Everett #213

@1.2
I tried again on an unpatched system (XAMPP 1.7.1, Windows 2000, FF 3.6).

Using tab, shift + tab I can move between the tab buttons in the strip of tabs. Pressing enter activates the respective tab pane but leaves the keyboard focus on the tab button. There's no way to actually enter the tab pane using only the keyboard.

The patch solves this problem by changing the behavior so that the focus is set to the first field of the tab pane when pressing the enter key. When on the tab pane using tab, shift + tab lets you move among the fields on the tab pane. Pressing the enter key while being anywhere in the tab pane will bring you back to the respective tab button (with the exception of text area fields for making multiple line entries possible).

hth
Frank

Everett Zufelt’s picture

@Frank

On an unpatched system, if focus is on the last tab button in the tabstrip and you press tab, where does the focus go?

Bojhan’s picture

Status: Reviewed & tested by the community » Needs work

Since a lot of questions are raised, how it actually works - I am putting it back to needs work, not obvious apparently.

Everett Zufelt’s picture

@bojhan

Thanks for setting this back to needs work, I didn't notice the status had been changed.

Frank Ralf’s picture

Status: Needs work » Needs review

Setting this to "needs review" by the same token as http://drupal.org/node/448292#comment-2634666

@Bojhan
Admittedly this is a very long thread but most of the questions have already been dealt with.

mgifford’s picture

The introduction of vertical tabs is a nice feature, but as we've been saying (since it got into D7) it has some significant accessibility problems that will set accessibility back for Drupal if we don't deal with them. Considering all the efforts that have gone into accessibility improvements in Drupal over the last two years I don't see this as acceptable.

Even in Drupal 6 people could just use a keyboard to navigate through and administer Drupal. As it is in Drupal 7 you can't.

One of the issues that we've struggled with for keyboard navigation is that it is often difficult to tell exactly where you are. Changing the element so that it looks more distinct on focus helps position keyboard users. There are probably better ways to deal with this, but it was overlooked in the designs of Seven.

There are questions about how this will work for both keyboard only users and screen-readers. We do need to have this functionality better documented. I would like to see an accessibility help link available from /admin/help this needs to be documented clearly so that people know that it is there and how to use it. As I've said with the Drag/Drop issue, I didn't know that it was navigatable with a keyboard until @webchick told me it was.

@Bojhan do you want to know "how it actually works" in terms of better user documentation or a technical description of what it is doing? Also, if there are design changes in the patch that you feel are incorrect, can you suggest a way that we can keep them more in line with the vision of Seven?

Everett Zufelt’s picture

I would really like to have a few clear responses (in one place) on the following questions:

1. Description in detail of current problem for keyboard only users.

2. Description in detail of current problem for screen-reader users.

3. Description in detail of current problem for low vision users.

4. Do any issues in 1 - 3 make the vertical tabs unusable by any group of users?

5. How are 1 - 3 addressed in the current patch?

This might be annoying and repetitive of earlier comments, but I really think it will help us all to get a clearer understanding of the issue and to get the solution over the hump and into d7.

Everett Zufelt’s picture

Just to follow-up on my prior comment. I think that all of the collaboration and effort that has been put into this issue should make it into Drupal 7. It would be incredibly disappointing to me for this issue not to be resolved.

Without answers to my questions in the prior comment I do not think we will get this into D7, I am quite certain we will not. I hope we can rally the troops for one final collaborative effort on this issue.

Frank Ralf’s picture

@Everett

I hope I will find the time to answer your questions today.

Frank Ralf’s picture

There's been a slight modification to vertical-tabs.js during one of the recent updates so I had to re-roll the patch to make it work again.

Status: Needs review » Needs work

The last submitted patch, vertical-tabs_467296.232.patch, failed testing.

Frank Ralf’s picture

Another try.

Frank Ralf’s picture

Status: Needs work » Needs review

Changing status.

mgifford’s picture

Hi @Ezufelt

1. Description in detail of current problem for keyboard only users.

Using just my keyboard I can only highlight the left main headings for everything in the vertical tabs. So in my sandbox, when I go to /node/add/article I can only tab through and highlight these items:

* Menu settings
* Book outline
* Revision information
* URL path settings
* Comment settings
* Authoring information
* Publishing options

I can't edit anything within them. So a keyboard only user cannot change any of the items in the vertical tabs as it is right now.

2. Description in detail of current problem for screen-reader users.

Not sure it is a problem. I'm sure I'd have heard if there was one.

3. Description in detail of current problem for low vision users.

There isn't as much contrast in Seven. I've tried to outline them here - http://drupal.org/node/740756

4. Do any issues in 1 - 3 make the vertical tabs unusable by any group of users?

Absolutely. #1 makes it unusable for sure. If you don't have a mouse you can't currently edit anything in vertical tabs. You can look at it, but that's all. This is a critical patch in my view!

5. How are 1 - 3 addressed in the current patch?

The patch adds in functionality so that you can use the arrow keys & tab to get into the main content area and edit it.

A lot of this has been explained more. We really need to have an accessibility help page that describes how this works. However, I haven't seen it yet.

Frank Ralf’s picture

@mgifford
Thanks for stepping in!

Just a clarification to 5):

The patch makes changes in two separate (and independent) areas:

a) Keyboard behavior (that's what we're talking about here).

b) Visual indicators for keyboard users (this can be factored out, e.g. in a separate theme).

Behavior without the patch:

Using tab, shift + tab you can move between the tab buttons in the strip of tabs. Pressing enter activates the respective tab pane but leaves the keyboard focus on the tab button. There's no way to actually enter the tab pane using only the keyboard.

Behavior with the patch:

The patch solves this problem by changing the behavior so that the focus is set to the first field of the tab pane when pressing the enter key (not the arrow keys, as Mike said) . When on the tab pane using tab, shift + tab lets you move among the fields on the tab pane. Pressing the enter key while being anywhere in the tab pane will bring you back to the respective tab button (with the exception of text area fields for making multiple line entries possible).

The behavior of all other keys (arrow keys, space bar) is left unchanged. They behave identically on every form field with and without the patch.

So the patch adds only a single desired behavior for keyboard only users without disturbing any other behavior which IMHO is the least intrusive enhancement possible.

Bojhan’s picture

Ok factor it out in a seperate theme then, I have been clear enough. If you want this in core, it cannot have such an intrusive change to vertical tabs.

mgifford’s picture

FileSize
268.32 KB

@Bojhan, I really wish you were more clear in your stated objections. It blocks progress on these issues and I know that isn't your intention.

Factoring these out into a separate theme or module really isn't an option. Support for keyboard only users has been something that has been essentially supported since (well at least Drupal 6, but probably earlier). I think Drupal 7 is the first Drupal release which would limit use by keyboard only users (if we aren't able to properly address this issue).

I've attached 5 different screenshots of the vertical menus (note that they are condensed into a single attachment). I know which were taken before the patch & which were taken after the patch but 99% of Drupal 7 users wouldn't notice. Two of the three are accessible via the keyboard & thanks to many revisions by @Frank Ralf it seems to work fine & look like the pre-patched site.

So, if it's not visually different, it must be different in some other way you object to.

We're not just talking about a handful of users who would benefit from the accessibility enhancements we've been working for over the last two years, but millions in the USA alone:
http://www.census.gov/Press-Release/www/releases/archives/facts_for_feat...
http://www.ilru.org/healthwellness/html/census.html

Furthermore, there are increasingly legal obligations that are coming into effect, particularly in the Western world. Both Canada & the USA have now signed onto Convention on the Rights of Persons with Disabilities:
http://www.un.org/disabilities/convention/conventionfull.shtml

Please be more exact about what exactly you object to. If it's visuals, please provide CSS changes or at least a screenshot of what is wrong. If it's Javascript, please let us know what you object to.

Everett Zufelt’s picture

Priority: Normal » Critical

Based on @mgifford and @Frank's comments in #236 and #237 respectively it would seem to me that this issue is critical. Keyboard only users cannot access fields within vertical tab panes with D7 head.

Bojhan’s picture

Really I dont have to be convinced that this is important. See #221 and #219, I already explained that the outline we chose to indicate an tab on:focus was not the way this should go into core. And I see no discussion over trying out alternatives. I can only guess if Frank changed the visual style, but I see no mention of that.

The outline of #239 is somewhat better, but I would rather go for showing an underline on the link or something similar - rather then a visual outline.

mgifford’s picture

Hey Bojhan,

Ok, I'd read #221 and #219 previously & just re-read them now. They really aren't specific enough to know what you don't like. However, "I would rather go for showing an underline on the link or something similar - rather then a visual outline." is perfectly clear.

So, if that's the only remaining issue, let's break that down into options for how tab headings will be displayed on focus for keyboard only users:
1) outline box with dots
2) underline the link text only
3) make the focus display look exactly like the hover display

Personally, I don't really care as long as keyboard only users are able to edit the content.

Practically, the outline is more consistent with how I think a keyboard only user would expect to see it. Those little dotted lines are pretty much identical to those which one would get when jumping between the focus on links. I think Keyboard only users would have no trouble understanding what it is or how it looks. That being said I'm usually happy when there is more highlight to the focus than the browser provides.

I think just underlining the link would be confusing as it's changing the function of what links do. Generally links send a user somewhere else.

Perfection, would I think be having the mouse navigation & keyboard navigation to look essentially identical. So rather than having a dotted line around it, the background would become distinctively lighter.

My only concern with this is that I'm not sure that visually there is enough contrast between the three states of the vertical tabs. Active is clear, but there is only a subtle difference between the Inactive color & the Focus/Hover color.

So, if we're agreed on implementing this patch with one of the three visual solutions implemented above then @Frank, are there any barriers with making hover/focus behave the same way visually? Also, is there any way to make it themable? I do think it would be cool to be able to just edit either the styel.css file or seven.info file & have it over-ride the settings displayed by the javascript.

I think we're getting closer.

Frank Ralf’s picture

I choose outline and system colors as a means for visual highlighting because they are theme independent.

And I think distinguishing between mouse hover and focus is important so keyboard users can see whether they are navigating with the keyboard and not with the mouse cursor which might be lingering over some area on the vertical tabs.

Everett Zufelt’s picture

@Frank

Does the patch in #234 add a heading before the vertical tabstrip?

If not I am thinking that we can modify theme_vertical_tabs() to add a heading.

Possibly something like:

'<h2 class="element-invisible">' . t('Vertical Tabstrip') . '</h2>'

Perhaps some instructions like 'Selecting a tab will change the form that follows'. But, this might be to much.

Frank Ralf’s picture

@Everett

I will have a look. But IMHO this should better be put in theme_vertical_tabs() anyhow, as JavaScript code should only/mainly be for the behavior of vertical tabs.

Mike Gifford might know more about this.

Everett Zufelt’s picture

@Frank

Sorry if I wasn't clear. I meant that we would put the heading in theme_vertical_tabs(), not in the JS. I figured we could roll it into the same patch, as the issue title is general to improving accessibility for vertical tabs.

Frank Ralf’s picture

Here's the patch with a modified CSS according to mgifford's suggestions in #242.
Everett's suggestion from #244 is not yet included.

Everett Zufelt’s picture

Curious why we decided we needed to allow enter to move between tabstrip and tab pane? Not criticising, just don't recall the reasoning and issue tracker pages with this many comments seem to kill my screen-reader.

Frank Ralf’s picture

@Everett

We decided on the Enter key to get back from the selected tab pane to its tab button for two reasons:

1) The tabbing behavior is the same as with Drupal's usual collapsible fieldsets (from which the vertical tabs are derived, see #61): You can tab through all collapsed fieldsets and toggle the opening and closing of the fieldsets using the enter key (see #101).

2) All other keys already have their familiar function/behavior within the context of a form:
- tab/shift tab for moving back back and forth.
- spacebar for toggling the status of checkboxes
- left/right arrow for changing the status of radio buttons

So the enter key was the most natural choice for a consistent user experience.

mgifford’s picture

I've added in the header that @Everett suggested & tested the patch. It seems to work fine.

I didn't modify the .js or .css files of the previous patch. Just added the includes/form.inc change.

mgifford’s picture

Duplicate, sorry.

mgifford’s picture

This screen cast isn't going to be visible to anyone using a screen-reader (@Everett & others), but it should help demonstrate how the patch at #250 looks in Seven & how it functions with just a keyboard. It is a pretty boring video, but for folk who like visuals.

http://screenr.com/ppg

Bojhan’s picture

Ok, agreed on the rationale for this change and the visual changes along with that. Lets put this off to RTBC if everyone agrees!

Frank Ralf’s picture

Status: Needs review » Reviewed & tested by the community

Thanks Bojhan! Changed the status accordingly.

bowersox’s picture

Wow! Based on the screencast (#252) this appears to be a wonderful improvement! You all have done an amazing job!

Everett Zufelt’s picture

Status: Reviewed & tested by the community » Needs review

Setting back to NR. I think we could use a peer code review before this patch is ready for RTBC. Please correct me if this patch has received code review from someone not involved in developing the patch.

Frank Ralf’s picture

Bojhan to the rescue ;-)

Jacine’s picture

I can't really review the JavaScript, but there's my 2 cents on the CSS file :)

+++ misc/vertical-tabs.css	16 Mar 2010 20:03:49 -0000
@@ -40,28 +40,39 @@ div.vertical-tabs ul.vertical-tabs-list 
+

There are a few new empty lines scattered in the patch. That should not happen.

+++ misc/vertical-tabs.css	16 Mar 2010 20:03:49 -0000
@@ -40,28 +40,39 @@ div.vertical-tabs ul.vertical-tabs-list 
-  background: #fff;
+  background-color: white;

The background-color change is probably fine, but can we please go back to the hex value for consistency?

+++ misc/vertical-tabs.css	16 Mar 2010 20:03:49 -0000
@@ -40,28 +40,39 @@ div.vertical-tabs ul.vertical-tabs-list 
+  font-size: smaller;
+  padding-bottom: 0;

Can we please remove the font-size here? The .summary class is already on a <small> tag, so any additional font-size adjustments belong in the theme. Also, is the padding-bottom: 0 really needed?

Other than that, it looks good to me. Nice job :D

147 critical left. Go review some!

yoroy’s picture

Status: Needs review » Needs work

Needs work then

Frank Ralf’s picture

Status: Needs work » Needs review
FileSize
5.97 KB

Made all the changes suggested by Jacine (#258). Thanks for the feedback!

Status: Needs review » Needs work

The last submitted patch, vertical-tabs_467296.260.patch, failed testing.

Frank Ralf’s picture

Status: Needs review » Needs work

The system is complaining about some localization issue with JavaScript:

ExpandString translate, search and validate (LocaleTranslationFunctionalTest) [Locale]

locale.test	LocaleTranslationFunctionalTest->testJavaScriptTranslation()
(lines 348 and 355)

As the JavaScript hasn't changed from the last passed patches I suppose there might be some problem with the test script.

EDIT
Just retesting did work.

Frank Ralf’s picture

Status: Needs work » Needs review

#260: vertical-tabs_467296.260.patch queued for re-testing.

Frank Ralf’s picture

Status: Needs work » Needs review
FileSize
6.1 KB

Re-rolled the patch because of recent modifications to vertical-tabs.js.

Frank Ralf’s picture

Status: Needs review » Reviewed & tested by the community

Patch does work with the latest release of HEAD, so setting this to RTBC.

mgifford’s picture

I'm confirming this as RTBC, this patch maintains the functionality and I didn't notice any javascript changes.. I just wanted to highlight the differences as I've seen it in comparison with the previous one.

You set up the fieldsets variable to handle > better than the fieldset did previously:

       // Check if there are some fieldsets that can be converted to vertical-tabs
       var $fieldsets = $('> fieldset', this);
       if ($fieldsets.length == 0) {
         return;
       }

You consolidated references to the tab link:

     .append(tab.link = $('<a href="#"></a>')

It does seem like the spacing is off on this line, but that's not serious.

Frank Ralf’s picture

@mgifford
Those changes are not by me but were already included in the most recent version 1.10 of vertical-tabs.js:

#741726: Move Filter module's vertical tabs extensions into vertical-tabs.js
#567224: Vertical tabs still appears, even if empty

mgifford’s picture

Great. Thanks for clarifying!

I should have read that from the diff.

yoroy’s picture

For when a core committer comes by this issue: maybe somebody can give a summary of the agreed on approach here, or point out the crucial comments to read? Reading 268 comments is probably not the best way for dries or webchick to know what the problem and solution is here.

Frank Ralf’s picture

@yoroy

For a summary which issues this patch addresses and how and why please read #236, #237, (#243 - using system colors - was dropped in favor of #242), and #249.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Thanks, all, for the great and thorough discussion here. And thanks too for the highlights. :)

I tried the latest patch and noticed no visual differences, which I know was a big concern earlier in the issue. Glancing through the code, this looks good, and I can see how this would make a vast improvement over the current situation. I wasn't sure about chr(13) stuff, but if it has sign-off from the a11y team then good enough for me!

Committed to HEAD! w00t! :)

mgifford’s picture

That's great news!

Status: Fixed » Closed (fixed)
Issue tags: -Needs usability review, -Accessibility, -vertical tabs, -D7UX usability

Automatically closed -- issue fixed for 2 weeks with no activity.

nithinkolekar’s picture

Issue summary: View changes
Status: Closed (fixed) » Active

facing the same issue as #567390: Use vertical tabs with keyboard only and posting here as this is a parent issue for all other issues.

OP's issue from #567390: Use vertical tabs with keyboard only

When not using the mouse it's not easy to goto the next tab, if you use the tab key at the last field on a tab, you move to the submit button instead of going to the first field on the next tab (if any)

This still not working with the latest drupal 7.37.

Is there any other element which is more easily accessible than vertical tab that makes this issue inactive from long time?

Frank Ralf’s picture

Status: Active » Closed (fixed)

Please don't re-open this more than five year old and rather long issue but create a new one if you face the same or a similar problem.

TIA
Frank