Review Views JavaScript + generic modals for accessibility

tag

Concerns / Issues / Comments

This isn't directly related to Views, but if you're using keyboard only - the Toolbar has to go, even using the skip link you still have to cycle through all the items in the Toolbar. This is more of a note than an issue.

Second widget screen unnavigable. Example: tab-navigate to add a filter, hit enter, modal appears, scroll through filters marking checkboxes with the spacebar, navigate to "Apply" and hit enter. This brings up the second page of the filter you want to add, however no amount of tab navigation will ever focus the user in this window. The only solution now is to press Esc and navigate to the new filter and hit Enter/Return to bring up that settings modal with proper focus.
This is the case in every scenario in which a second window of options is presented.

Focus is lost when you 'Esc' out of some popup windows. Using that filter example again, once I go back to edit the settings of the filter I added - If I change my mind and decide to do something else by using 'Esc' to close the window, focus is lost entirely and it's impossible to tab navigate without reloading the page.

Long lists of options are currently... really long. In the example I used above, I mentioned marking the filters I wanted via the spacebar - But what if I only want to add 2 or 3 filters? It is a very long list to go through and choose a filter and then get to the Apply button. Obviously, the solution here is to just search for the filter desired in the search area - but is there a better way to navigate directly to the Apply button or buttons area?

Every time an action is executed (e.g.: applying anything or cancelling something) focus is reset to the top of the page when it is not lost entirely. I'm not sure whether or not anything can be done about that - but maybe there's some magic JS stuff we could do to improve things.

-- More notes to follow this, I have to do real job things for a while :)

Dang. Not what I was hoping to hear. It's extremely valuable to have this information, though--I look forward to further results!

One thing I'd suggest is, once you've completed all the testing, try the "disable views Javascript" option under the Views settings and repeat the testing to see if the UI works that way.

It appears that the first issue mentioned is not just toolbar; the "skip to main content" link does not place the cursor focus in the main content area ever, at least from my testing. Edit: I opened #1823308: Should the "skip to main content" link place cursor focus in the main content area?.

Second widget screen unnavigable. Example: tab-navigate to add a filter, hit enter, modal appears, scroll through filters marking checkboxes with the spacebar, navigate to "Apply" and hit enter. This brings up the second page of the filter you want to add, however no amount of tab navigation will ever focus the user in this window. The only solution now is to press Esc and navigate to the new filter and hit Enter/Return to bring up that settings modal with proper focus.
This is the case in every scenario in which a second window of options is presented.

I just confirmed this locally. This is the main critical bug here so far (the others might be major or normal, but this one renders an entire part of the workflow inoperable).

Interesting sidenote: the modals actually appear to be broken with overlay currently, so if you enable overlay, then you can keyboard-navigate adding a field!

Edit: I also confirmed that the second dialog is usable if you disable the JS completely under the advanced view settings; the effect is the same as the broken modals in overlay. ;)

@xjm thanks for confirming my tests / extending them. I had planned on doing this without js enabled as well but you beat me to it :)

Anyone in a position to start drafting a patch for this?

@mgifford, I think the first step is #1667742: Add abstracted dialog to core (resolves accessibility bug).

Any more manual testing needed? Or is this postponed on #1667742: Add abstracted dialog to core (resolves accessibility bug) ?

The other issue is for sure somehow a major blocker, but maybe without that we can open already new issues to fix.

The problem is that we can't finish testing whether it's keyboard-usable, because we can't even use it with a keyboard at all. :) And bugs that exist with our modal will not necessarily exist with the new modal, and the new modal may introduce other bugs as well. I've considered several times postponing this issue on the other.

Talked to @webchick and @catch about this issue. Postponing this issue, but bumping the priority of #1667742: Add abstracted dialog to core (resolves accessibility bug). (It might end up being a duplicate). Thanks carwin, mgifford, Cottser!

The modal is in now, so the next step is to convert views: #1851414: Convert Views to use the abstracted dialog modal.

VIEWS IS IN CORE

This is a related issue for both screen reader users and also keyboard only users #1824636: Do not move the cursor to the top of the page on ajax calls

The focus coming back from a modal dialog is the top of the page which is really annoying for anyone who wants to go through and say edit all of the elements of a view.

This is still blocked on #1851414: Convert Views to use the abstracted dialog modal isn't it?

yes. patch is close. some unusual views requirements on the models are holding it up.

I tested the scenario described by carwin in #5 against the patch posted by nod_ in #1851414-105: Convert Views to use the abstracted dialog modal. The problem with focus in the second dialog screen is resolved. It is possible to configure Views with a keyboard given this patch. I'm reluctant to take the manipulation of focus any further such as moving the focus of the active element to the first focusable element in the admin page content area. I have gotten opinions from blind user who prefer the focus to always start at the top of the page so that they can orient themselves.

I think we can close this issue once #1851414: Convert Views to use the abstracted dialog modal is committed.

Makes sense to me.

I committed #1851414: Convert Views to use the abstracted dialog modal. We now have no known bug, but would be good to explicitly test this before closing the issue. Moving over to a task.

This task is very open ended. I would rather address specific issues as they arise than try to satisfy a critical with no clear success criteria. I've gone through the Views UI with a keyboard since the commit of #1851414: Convert Views to use the abstracted dialog modal. I can at least get to all the UI elements. Sure, there may be refinements to be made, but we can make them with narrow-focused issues. Given our critical queue's length, I'd rather close this now so we can focus energy on issues that have boundaries.

I'm going to tentatively RTBC this to get it on people's radar as an issue that's been, as far as we can tell, resolved.

Hm. The issue title still seems actionable to me. While being able to navigate to all of the pages in general is awesome, that by itself doesn't prove that Views actually works for keyboard-only users.

Maybe what's needed to un-open-end it is a concrete test case. Talked to Tim. How about, re-create the frontpage view using only a keyboard, and also ensure that the preview functions in a screen reader?

I tried to create the frontpage view and ran into some problems as you cannot submit the frontpage filter form on initial try. Maybe this is a behavior caused by chrome.

moving to major since the individual parts should be accessible hence I'm not expecting huge issues to come up.

These are the issues I ran into while testing the recreation of the front page view using only a keyboard:

#2124397: Keyboard focus is lost after an AJAX page update
#2124405: Take advantage of ARIA roles (specifically widget roles) to enrich the non-visual interface of Views
#2124415: Use Drupal.announce to give a screen reader user a succinct summary of how changes to a View's definition affected the preview

None of these issues are blocking in terms of this critical/major. They represent refinements to user interfaces and interactions.

I was able to recreate the font page list of content and even refine it, switching the filtering from Articles to Pages.

It's my opinion that we can close this issue in favor of specific issues like those listed in this comment.

Removing myself from the author field so that I can unfollow. --xjm

That's great! :) Thanks, Jesse.

I've added those issues as "related" issue to this one, and I agree that it sounds like the major/critical of this is officially DONE. YEAH!