Though a user can properly navigate the tab structure with keyboard command they are not taken to the content within the tab when the tab is opened with RET.

There was some great work done with vertical tabs in core https://www.drupal.org/node/467296 where upon selecting RET the user is taken into the opened content and able to tab through the links inside. To exit they either continue tabbing of back out using SHIFT-TAB.

Making this the behavior in view_vertical_tabs would make navigable by keyboard and accessible.

Comments

schiavone’s picture

Issue summary: View changes
jibran’s picture

Thanks for creating the issue. I'm not an accessibility expert so I didn't totally understand the problem space here. In this module we are using core vertical_tabs element to render the output maybe we are missing something when we create render array.

Can you please add step by step instruction? In this case let suppose we have a page view of vertical tabs and from there give me keyboard instructions so that it helps me understand the problem.

schiavone’s picture

The desired behavior on pressing the enter key is to give focus to the pane and select the first link there if one exists. Currently, focus is not given to links within the pane so keyboard navigation is not possible.

I've been digging in to understand what would be needed. I saw that core vertical_tabs is being extended that will make things easier. In core we have...

  // Keyboard events added:
  // Pressing the Enter key will open the tab pane.
  this.link.keydown(function(event) {
    if (event.keyCode == 13) {
      self.focus();
      // Set focus on the first input field of the visible fieldset/tab pane.
      $("fieldset.vertical-tabs-pane :input:visible:enabled:first").focus();
      return false;
    }
  });

This doesn't happen in the module I think because...

#1 - we're looking for a field (the tabs in the edit node screen seem to always start with a field. After that you can navigate links using TAB and SHIFT-TAB)

Otherwise it looks like the pane object is using the same selector.

I'm still wrapping my head around how navigating tabs works. I'll take a look at what's in core to see if I can identify anything else.

schiavone’s picture

Successfully selected the first link within the pane by replacing...

$("fieldset.vertical-tabs-pane :input:visible:enabled:first").focus();

with

$("fieldset.vertical-tabs-pane a:visible:first").focus();

in core misc/vertical-tabs.js

So does this issue move into core or can the jQuery function in core be overridden by the module?

jibran’s picture

Issue tags: +JavaScript, +Accessibility

Yeah I think it's worth moving to core but for core it's a bug not a feature. If it doesn't get fixed in core issue queue then we can think about fixing it in views_vertical_tabs.
$("fieldset.vertical-tabs-pane a:visible:first").focus(); doesn't this break for form api?

schiavone’s picture

From what I can see the link selection is not needed in core so I'm trying to see if the core function and be extended in the module. Not expert in jQuery so it's taking me a bit of time. This way at the very least others can extend the function in in a custom module or in the theme or perhaps the this module can be patched to support navigating to the first link in the pane.

schiavone’s picture

This snippet will move focus to the first link within the pane.

Drupal.behaviors.viewsVerticalTabs = {
attach: function (context, settings) {
  // Bring user to first link in pane when ENTER key is used to select
  $('.vertical-tab-button a').keydown(function(event) {
    if (event.keyCode == 13) {
      $("fieldset.vertical-tabs-pane a:visible:first").focus();
      return false;
    }
  });
  }
  };

A function like this could be implemented in the module or the core function above could be extended to support giving focus to the first link if a field was unavailable. Continuing to tab should bring the user back to the active tab (needs work).

rooby’s picture

I would argue this still should be a Drupal core bug report.

Even though node forms and such have inputs to focus into, Drupal core is supposed to be providing generic functionality that works correctly if you use it for your own purpose. If that is not the case then that is a bug in Drupal core.

It could be overridden in this module as you suggest though if Drupal core maintainers would not consider changing the core functionality.

mgifford’s picture

Raising this as a separate issue in Core is a good way of raising awareness of this issue. Fixing things in Core is slow though, so I wouldn't close this here.