Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature tabbing bypass blocks #280

Closed
prushforth opened this issue Feb 2, 2021 · 13 comments · Fixed by #270
Closed

Feature tabbing bypass blocks #280

prushforth opened this issue Feb 2, 2021 · 13 comments · Fixed by #270

Comments

@prushforth
Copy link
Member

prushforth commented Feb 2, 2021

That's a convention sometimes referred to as "skip links": https://webaim.org/techniques/skipnav/.
Here's an example: https://genericcomponents.netlify.app/generic-skiplink/demo/index.html.

It works by using a CSS hack to visually hide the links and unhide them as they recieve focus. There is no standard way to hide something that's intended to be focusable (related discussions, FWIW: w3c/csswg-drafts#560, w3c/css-a11y#13).

It's indeed helpful, it relates to SC 2.4.1 Bypass Blocks. I suppose I can see a standard implementation of it (both as a CSS property and as a default facility in maps) but I think that's also based on assumptions of how users currently interact with maps (and what is keyboard accessible, under which circumstances).

Originally posted by @Malvoz in #264 (comment)

Was discussing with Ahmad, we think having a forward/backward bypass block mechanism built into the (popup) UI would be helpful / essential. When you tab to a feature, then tab into its (popup) UI, the tab sequence could include a fast forward/backward affordance to get to the end of the feature tab sequence quickly. So the "normal" tab-through-features sequence would be interruptible by drilling into one feature and activating its bypass block.

image

@Malvoz
Copy link
Member

Malvoz commented Feb 2, 2021

I'm not sure I understand the description of the solution. Is the problem: 1) focus a feature 2) press Enter or Space to open popup 3) next tab focuses the next feature instead of the popup (or content within the popup)? If I understood correctly, and the implementation relies on current Leaflet functionality, the upstream issue is Leaflet/Leaflet#2199 (tracked in #247).

Edit: that upstream Leaflet issue only partially solves the problem, once a popup has been closed the corresponding feature should recieve focus. Because currently when you close a popup the body element recieves focus which is pretty bad. This is tracked as a separate item under "Popups" in #247 with a "Upstream Leaflet: TBD".

@prushforth
Copy link
Member Author

prushforth commented Feb 2, 2021

  1. focus a feature 2) press Enter or Space to open popup 3) next tab focuses the next feature instead of the popup (or content within the popup)?

the upstream issue is Leaflet/Leaflet#2199 (tracked in #247).

Edit: that upstream Leaflet issue only partially solves the problem, once a popup has been closed the corresponding feature should recieve focus. Because currently when you close a popup the body element recieves focus which is pretty bad. This is tracked as a separate item under "Popups" in #247 with a "Upstream Leaflet: TBD".

@ahmadayubi note the focus problem is in Leaflet, directly. If we can figure out how to solve that problem maybe it's worth trying to submit a fix upstream? Community support and all that TBD.

However, the issue here is there may be a lot of features to tab through, and having a shortcut forward or backwards to the rest of the DOM content after or before the map might be useful.

@ahmadayubi
Copy link
Member

ahmadayubi commented Feb 3, 2021

Within the custom element you can create a hack to focus the popup followed by the next feature but this hack isn't going to change the DOM structure leaflet generates, where they have the popups in a separate div after all the features in the DOM. It's going to be using JavaScript rather than DOM order, ideally it wouldn't need JavaScript but that is on Leaflet's end, and a big change on their part (changing their internal structure and all).

It would be good to submit a fix upstream but it's a big fix, having to change their internal structure.

@Malvoz
Copy link
Member

Malvoz commented Feb 3, 2021

@ahmadayubi note the focus problem is in Leaflet, directly. If we can figure out how to solve that problem maybe it's worth trying to submit a fix upstream? Community support and all that TBD.

A Leaflet user implemented a similar "hack", albeit in JQuery: http://melmo.github.io/accessibility/code/dist/leaflet.html (the article mentions other non-related or tangentially related issues, some of which Leaflet has fixed already). It uses a negative tabindex to enable programmatic focus such that the element is otherwise excluded from the natural tab order.

I think Leaflet would rather go that route rather than changing the DOM structure since that may not be backwards compatible with people's code.

@ahmadayubi
Copy link
Member

2021-02-03.11-27-15.mp4

Going to add these changes to PR #270 and link this issue in there also.

@prushforth
Copy link
Member Author

prushforth commented Feb 3, 2021

To me, this looks close to what I think could be a good UI, but I'd appreciate others comments:

image

I think the "Skip to the end" icons should be something like this

image

I think there should be a "1 / n" output indicator, where "n" will always be 1 when tabbing through the feature set, but "n" could be many features when navigating a set of features returned by a query from a server. I think there should be right-pointing arrow beside or above, but associated to the "1 / n" readout, that when activated goes to either the next feature of the "n" or the next feature in the tab order".

@Malvoz
Copy link
Member

Malvoz commented Feb 3, 2021

"skip forwards" and "skip backwards" are very generic descriptions, they're pretty confusing to me. I don't think enough context is provided.

@prushforth
Copy link
Member Author

prushforth commented Feb 3, 2021

image

The double chevron with a vertical bar often signifies to skip past everything in the sequence. I took "bypass block" to mean effectively this - the user doesn't want to have to be trapped in a long sequence of tabbing, so if they open the popup on any feature, they will be placed (on one of the affordances) in the bypass block, allowing them an early exit from the tab sequence, but only being accessible by opening the / any focused feature. On the other hand, maybe they want, having looked / listened briefly to the content of the focused feature, to go to the next feature in the tab sequence. For that, they use the single right- or left-pointing arrow head (looks like a 'play' icon except is often used for scrolling through a sequence of things, hence pointing in both directions).

A challenge here is to leverage the same user interface for query results as for feature tab sequences.

"skip forwards" and "skip backwards" are very generic descriptions, they're pretty confusing to me. I don't think enough context is provided.

So: left-pointing single arrow = "previous"; right-pointing single arrow = "Next", double arrow with a vertical bar is the bypass block. Is that enough context?

@Malvoz
Copy link
Member

Malvoz commented Feb 3, 2021

The double chevron with a vertical bar often signifies to skip past everything in the sequence. I took "bypass block" to mean effectively this - the user doesn't want to have to be trapped in a long sequence of tabbing, so if they open the popup on any feature, they will be placed (on one of the affordances) in the bypass block, allowing them an early exit from the tab sequence

Yes that is correct. Skip links are usually descriptive of what it's taking the user to, so for example the most common implementation of skip links is "Skip to main content" (<main>) to bypass the site navigation links. But these labels don't identify the thing.

And the fact that they're the first thing encountered in a popup may also be confusing (or even that they're inside the popups, although I don't think there is a better place) because the user has just made an action to explore details for a particular feature.

@prushforth
Copy link
Member Author

the fact that they're the first thing encountered in a popup may also be confusing (or even that they're inside the popups, although I don't think there is a better place) because the user has just made an action to explore details for a particular feature.

Yes, I agree, I was thinking that it's something users might become accustomed to / eventually understand that to get out of the tab sequence they could open any / the next focusable item and find the affordance there.

If they weren't the first thing focused when a popup opened i.e. we force the user to shift-tab to get to them, would that be less confusing? Or more confusing?

@Malvoz
Copy link
Member

Malvoz commented Feb 3, 2021

I think moving mapml-focus-buttons inside leaflet-popup-content-wrapper and after leaflet-popup-content in the DOM would be the most logical, it also doesn't require the user to shift-tab. So the user would a) open the popup b) get the details for the feature (highly dependent on popup container recieving focus, see the example I linked to in #280 (comment), for screen readers to announce the content) c) tab to the pagination buttons d) tab to close button (if that's re-introduced).

@ahmadayubi
Copy link
Member

ahmadayubi commented Feb 4, 2021

Originally it was inside the content-wrapper but leaflet internally disables interaction with content inside the wrapper, so I had to move it out of there and into the container itself.

Turns out you can add to the content after the popup is created, force focus and the buttons seem to work.

@ahmadayubi
Copy link
Member

Latest version:

2021-02-04.13-27-08.mp4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants