Overscroll Areas feel like they should be done through CSS

[bramus]

Hi, Chrome DevRel here 👋

I saw that in whatwg/html#12273 @keithamus challenged us/me to come up with a different way of doing things.

flackr: devrel said that the button is awful
keithamus: i could imagine the pushback, and i would challenge them and wonder whether theres another way to do it

Well, I think I have something, so here goes …

---

Table of Contents:

• The Main Take
• But, why CSS then?
  • Example 1: Navigation / Drawer Menu
  • Example 2: E-mail Interface
• But what about Accessibility?
  • Interfaces should already be accessible
    • Applied to the Drawer Menu
    • Applied to the E-mail Interface
  • Use aria-actions when there is no command button to toggle an overscroll area
• So, what would a CSS opt-in look like?

---

The Main Take

In the current proposal for Declarative Overscroll Actions an HTML attribute on the container is used as the opt-in mechanism to enable overscroll areas.

First, the container needs to be identified as supporting overscroll areas. This is done by specifying overscrollcontainer attribute on the container.

To cut to the chase, I think that using an attribute as an opt-in mechanism is wrong, and I believe that, instead, this opt-in should be done through CSS.

There is also the command button to toggle overscroll that is part of the proposal:

Second, we introduce a new command value, toggle-overscroll, to bind a trigger button to both the container (the scroll port) and the content (the element hidden in the overscroll area).

In a previous iteration of the proposal, this button was also necessary to make something an overscroll area (see this (outdated) code example), but that — thankfully — is no longer the case: the command button is nowadays only concerned with scrolling an overscroll area into or out of view.

(So to correct the meeting minutes: devrel said that the button is awful as the way to make something an overscroll area ;))

But, why CSS then?

In my perception, Overscroll Areas are very much layout dependent: depending on what screen size you are looking at something, an element might always be in view (e.g. on the big screen layout) or tucked away behind a button that can toggle it (e.g. on the small screen layout).

Furthermore some Overscroll Areas may be presented without a Command Button to overscroll that area being present at all.

Finally, a container might have multiple overscroll areas, each with their own overlay mode, so one single attribute on the container won’t cut it.

Let’s take a look at some examples to clarify this …

Example 1: Navigation / Drawer Menu

Let’s look at a navigation menu. On a large screen layout this would be a side-column that is typically placed next to the content. On a small screen layout this becomes a drawer menu that you either reveal by pressing a hamburger button somewhere or — and this is what overscroll areas try to achieve — by scrolling from the edge of the screen to reveal said menu.

This is a common pattern on sites, for example on Bsky:

Figure: Bluesky on a large screen. The menu is positioned to the left of the main content column.

Closed Menu	Open Menu

Figure: Bluesky on a small screen. The menu becomes a drawer menu that gets actived by a hamburger button. When visible, the drawer menu lays on top of the content. On a touchscreen device, a swipe gesture also reveals the menu.

If overscroll areas are defined in the markup (as it currently stands in the explainer), then there is no way to conditionally toggle that, whereas in CSS you can put this type of thing in a Media Query / Container Query.

Example 2: E-mail Interface

Another example is an e-mail interface. On the overview view you have a list of emails, and upon clicking one you go into a detail view that features the e-mail itself along with some buttons to reply, archive, etc.

Figure: The overview view of a fictitious e-mail interface. Shown are 4 emails. Some of these are favorited and/or unread.

Figure: The detail view of a fictitious e-mail interface. Included in this view is a back button and an action bar. The action bar has buttons to archive, favorite, and mark as unread.

What a lot of mobile interfaces do is augment the overview view by adding extra actions behind swipe gestures per e-mail.

Figure: The overview view of a fictitious e-mail interface, with some emails having their swipe actions revealed. When swiping from the left a “Mark as (un)read” button is presented. When swiping from the right a “Archive” button is presented.

While these swipe actions could be visible on both small and large screens, there are no command buttons present to reveal these overscroll actions. The archive and toggle buttons you see there are different buttons.

But what about Accessibility?

Good, I thought you’d never ask 🙃

Interfaces should already be accessible

Interfaces that get augmented with overscroll gestures should already be accessible regardless of overscroll gestures being added to it or not.

Applied to the Drawer Menu

In the case of the drawer menu example, a developer MUST already have a command button in place to show / hide that sidebar.

The current API proposal already has this in place, namely a command button that can send a toggle-overscroll command.

<button commandfor="menu" command="toggle-overscroll" id=btn aria-label="Reveal Menu">☰</button>

This button is still very much necessary, as it makes the interface accessible: you can tab into it, activate it to reveal the drawer menu, etc.

As a reminder: unlike the current proposal, this button here is not used for the opt-in to create an overscroll region, but it is used only for scrolling that overscroll area into view.

Applied to the E-mail Interface

As for the e-mail client interface: the actions that are exposed by the gestures should already be reachable through the regular UI.

Practically speaking, I would expect to be able to tab through the list of emails, and when at the e-mail detail view, I would expect that detail view to have buttons to archive the email and toggle its read state.

Therefore, I don’t think that this interface should have a command button with toggle-overscroll, because a user can already perform the actions that are tucked away through another mechanism or path.

(I think of this similar to adding keyboard shortcuts to an interface. While very handy, the actions that these shortcuts do can already be achieved through the interface)

Use aria-actions when there is no command button to toggle an overscroll area

To present these extra actions tucked away behind overscroll areas, aria-actions (See issue w3c/aria#1440 and accompanying (WIP) PR w3c/aria#1805) should be used to expose these in an accessible way.

In the drawer menu example this is not necessary, because there are already command buttons in the markup to either show or hide the menu.

In the e-mail interface using aria-actions is very much necessary because there are no command buttons.

By setting the aria-actions on the e-mail div to point to the already present buttons for archiving and toggling the read/unread state, this can be achieved:

<div class=email aria-actions="toggleread,archive">
  <a href="detail.html">…</a>
  <button id="toggleread" aria-label="Mark as read"><icon … /></button>
  <button id="archive" aria-label="Archive E-mail"><icon … /></button>
</div>

The exact markup is dependent on what aria-actions will end up looking like, but you should get the idea here: you link up the existing buttons (the very same ones presented to users who use overscroll) through aria-actions.

So, what would a CSS opt-in look like?

(Everything in this section is informational, but I did want to share it with you to give the full picture of how I think about Overscroll Areas.)

I don’t want to hinge this discussion on the exact shape of what this should look like, I am mainly seeking an agreement on that, perhaps, Overscroll Areas should be a CSS opt-in instead of an HTML opt-in.

However, I did my homework and created a prototype which you find at https://major-butterfly-redfish.codepen.app/ for you to explore. I’ve checked basic tabbing behavior, and VoiceOver announcing things, but nothing more.

Here’s a quick write-up of how it behaves. There is a lot of overlap with how the feature currently behaves, so not that much should be new:

• Overscroll areas use scroll-snapping
• Non-visible areas of overscroll areas are inerted, so you can’t tab into them.
• The toggle-overscroll command only makes that overscroll area visible, it doesn’t activate anything inside the now visible overscroll area.
• After an overscroll area becomes visible, there is a lot of behavior similar to a modal dialog being shown:
  • the rest of the contents in the parent scroller are inerted
  • the first focusable element inside the overscroll area gets focused
    • If there is no such element, the entire area gets focused.
  • visible overscroll areas are light dismissable
  • there are styleable backdrops

Some other things worth nothing with this proposal:

• (NEW) Overscroll Areas can be toggled on and off with Media Queries (or other conditions)
• (NEW) The opt-in is coupled with a positioning scheme that is inspired by anchor positioning’s 9-box grid and/or grid areas.
• (NEW) An Overscroll Area is a size container by default. Content inside an overscroll area can use container query units.
• (NEW) It is possible to define multiple overscroll areas, each with their own overlay mode. For example, content on the left can be “overlay”, whereas content on the right can be “normal” or “underlay”.

Again, please note that the CSS syntax from that prototype is not the core of this issue and is something that — if there is agreement on putting this in CSS — would need to be discussed at the CSS Working Group. The core of this issue is to get an agreement on that, perhaps, Overscroll Areas should be a CSS opt-in instead of an HTML opt-in.

/cc @vmpstr @flackr

[sb3nder]

I don't get the keyboard navigation story. In the case where there is no button, does one have to use something like accesskey or JavaScript to map a shortcut?

By setting the aria-actions on the email div to point to the already present buttons for archiving and toggling the read/unread state, this can be achieved.

aria-actions doesn't change anything about an element's function or behavior, right?

Also, from a very brief read of the aria-actions PR, I'm not sure it would work for non-accessible nodes.

---

Something I thought during the BlinkOn presentation was whether the container could become focusable, similar to overflow: auto containers, and if a shortcut like Ctrl+Alt+Arrow could be used to reveal overscroll in the corresponding direction when focus is inside that container.

[flackr]

Something I thought during the BlinkOn presentation was whether the container could become focusable, similar to overflow: auto containers

Yes, that's absolutely something we could do, to make sure that you can send key events to the container.

and if a shortcut like Ctrl+Alt+Arrow could be used to reveal overscroll in the corresponding direction when focus is inside that container.

We definitely could have a key combination and I think this has come up in this context before. The main challenge will be making sure that people are aware of it, that it feels like what you would expect, and also that it is not already taken at least by the OS.

[bramus]

I don't get the keyboard navigation story. In the case where there is no button, does one have to use something like accesskey or JavaScript to map a shortcut?

Nowadays scrollers themselves can be made focusable. So we could say that if one has aria-actions, it becomes focusable.

and if a shortcut like Ctrl+Alt+Arrow could be used to reveal overscroll in the corresponding direction when focus is inside that container.

We definitely could have a key combination and I think this has come up in this context before. The main challenge will be making sure that people are aware of it, that it feels like what you would expect, and also that it is not already taken at least by the OS.

MacOS’s voiceover announces “actions available” when tabbing onto an element has actions available.

With the VO-Command-Space bar shortcut that can be activated, after which it lists the actions, which you can then trigger:

[lukewarlow]

I think the discoverability concern would mostly be non-screen reader users. Especially those using an input modality without clear patterns for these sorts of things. On touch you might say that swipe is clear enough, but on desktop (or maybe tablet?) with a keyboard it might not be obvious that there are these actions nor how to get to them.

[bramus]

I think the discoverability concern would mostly be non-screen reader users. Especially those using an input modality without clear patterns for these sorts of things.

Is this really a problem if the means to reaching a specific goal are available elsewhere in the UI?

In the e-mail example, the archive and toggle read actions that are tucked away behind overscroll areas are just an extra means of invoking those actions, in addition to buttons available elsewhere in the UI. This similar to keyboard shortcuts being available (where the de facto standard is to hit ? to reveal instructions — try it on GitHub, YouTube, Gmail, etc.)

If authors really want, they could always inject some indicator based on the aria-actions attribute. However, I wouldn’t want the UA to do this automatically as it:

• Totally depends on the use-case. In the drawer menu example this would not be needed at all, as there are invoker buttons present in the UI.
• People, myself included, already have the natural tendency use gestures on interfaces they see and and use on both touch and non-touch devices. I’ve already caught myself multiple times trying to flick away a dialog, use click+drag to move a scroller, or just scroll on desktop to recreate a gesture I know from the touch-device interface.

On touch you might say that swipe is clear enough, but on desktop (or maybe tablet?) with a keyboard it might not be obvious that there are these actions nor how to get to them.

One thing we could consider here is allow revealing the overscroll gestures by means of the arrow keys. As in: when you’ve focused the main area of an overscroller, pressing the arrows could reveal (and focus) those overscroll areas.

(However, I’m not convinced of the above yet. At one point I had this in my prototype and it didn’t entirely feel right. This would need some user study and/or exploration of how other platforms currently do it)

Main point remains that I think people will naturally try these gestures. A parallel I like to draw is with the light dismissal of dialogs: people are naturally trying to click the backdrop or hit the ESC key to close the dialog, without that being expressed in text anywhere. Users who try (or know), find that it works. Users who don’t, just click the dialog close button that the UI provides.

[css-meeting-bot]

The Open UI Community Group just discussed Overscroll Areas feel like they should be done through CSS.

The full IRC log of that discussion

<dandclark> topic: Overscroll Areas feel like they should be done through CSS
<dandclark> github: https://github.com//issues/1457
<una> welcome bramus
<dandclark> bramus: There's currently the declarative overscroll actions proposal
<dandclark> ...vlad, flakr, and mason are authors
<dandclark> ...I gave some feedback previously discussed
<dandclark> ...after trying this out. The attribute felt like the wrong way to opt in.
<dandclark> ...when I look at some of the use cases for overscroll actions I feel they're tied to layout
<dandclark> ...One of the examples is the navigation drawer menu. On a widescreen layout the sidebar would just be a navigation bar
<dandclark> ...having the attribute as the opt in feels a bit wrong because it seems dependent on layout
<dandclark> ...For a while the opt out was an activation button to trigger, but it's unclear in the explainer if it's required
<dandclark> ...Based on this it seems it's layout dependent and should be in CSS.
<keithamus> q+
<dandclark> ...One of the things that comes with this is what about a11y.
<dandclark> ...If it's in CSS how do people discover the actions that can be taken.
<dandclark> ...In the email case I imagine a list of emails, you navigate to the email details page, where there are buttons to archive etc.
<dandclark> ...In the list with overscroll, you can slide to get these actions. But they're already availble to the basic interface.
<dandclark> ...Also aria-actions would allow solving that.
<dandclark> ...You can use aria-actions to expose the extra actions like archive etc
<dandclark> ...So you can augment your UI with overscroll actions, and the a11y bit is covered by the interface itself and aria-actions
<masonf> q?
<keithamus> q?
<gregwhitworth> ack keithamus
<dandclark> keithamus: I want to ask about aria-actions. My understanding is it's not yet implemented and shipped in meaningful capacity
<masonf> https://chromestatus.com/feature/5161589307867136
<dandclark> ...Is it a blocker for this?
<dandclark> sarah: It's shipped in Chrome, Firefox in technical preview
<dandclark> ...In JAWS, might not be in the main version of JAWS, need canary
<dandclark> ...NVDA does not, narrator does not
<dandclark> bramus: These actions are already available through regular UI so it's unfortunate it's not available to screen reader but maybe it's OK?
<dandclark> ...In all these examples there are other ways to achieve the action.
<keithamus> q?
<gregwhitworth> https://open-ui.org/components/overscroll-actions.explainer/#css-only-properties ????
<dandclark> keithamus: So what do we want to do with this? Is there proposed resolution?
<dandclark> bramus: Only resolution I'm seeking is 'yes maybe we should investigate how it can be done in CSS' and then it becomes CSSWG problem to discuss syntax
<dandclark> masonf: There already was CSS proposal
<dandclark> keithamus: Yes it got kicked here
<dandclark> ...are we going to go in circles?
<dandclark> flackr: The hope is that the people who moved us to attributes are present
<sorvell> +q
<dandclark> masonf: Conclusion can be stronger resolustion that it should move to CSS
<sarah> q+
<dandclark> keithamus: Might be a very kind of interesting testing ground for some of the work that ARIAWG is working on on CSSAAM
<dandclark> ...If we are to define this in CSS sounds like this is a strong case for a11y mappings to be well specifified
<dandclark> ...This needs to be socialized in front of ARIA WG, pushing for deep dive so they can understand the accessible parts of this.
<dandclark> ...That was the biggest challengs of overscroll areas to begin with, why it got kicked here.
<gregwhitworth> q+
<dandclark> ...If we're able to use this as opportunity to see what this means for a11y including aria actions, could make this more meaningful in CSSSWG as consequence.
<vmpstr> q+
<dandclark> ...Was originally proposed in CSSWG, pushback was we haven't figured out a11y, now we can push it back as long as we better define a11y
<dandclark> sorvell: Agree it seems this is related to layout and should be CSS feature.
<una> you can think of this as "swipeable areas"
<dandclark> ...Confuses me that it seems analogous to scroll snapping. Word 'overscroll' is confusing. That seems like what you get on iOS where you scroll to top temporarily. How is it different from normal scrolling?
<masonf> naming is hard
<keithamus> ack sorvell
<dandclark> ...If it's not, maybe that's source of confusion
<dandclark> bramus: It's a naming quesiton of the feature
<dandclark> ...It's also like overscroll because you can overscroll the scroller to activate
<dandclark> flackr: You can scroll past content of the element, then you get into the overscroll, so it's outside of the normal scroll
<dandclark> ...Analogous to the CSS overscroll property in that it affects how scroll chains.
<dandclark> sorvell: COnfusing thing for me is e.g. on mobile apps you can scroll beyond the top to refresh. To me that's overscroll because it snaps back.
<dandclark> ...It's persistent in bramus's examples
<dandclark> bramus: They are the same
<dandclark> sorvell: How is it different from scrolling to position not zero and scrollling back
<dandclark> flackr: If the question is naming that's separate discussion
<dandclark> ...Can we agree this should be CSS?
<dandclark> ...I don't think naming is related to that decision.
<keithamus> q?
<dandclark> masonf: I think there is already an issue about that but let's decide where it should go first.
<gregwhitworth> ack gregwhitworth
<dandclark> sarah: If I was involved in initial discussion I don't recall. The things I want to think about more are I think this would involve having a minimum role applied by the browser, needs to be focusable and have accessible name. that's not a blocker for moving to CSS.
<dandclark> ...What would be the minumal role that would also enable aria-actions? Default minimal role would be group.
<dandclark> ...Not sure about aria-actions on group role.
<dandclark> ...Can't think of reason why it wouldn't work but isn't one of the allowed roles currently.
<dandclark> ...Want to check in with screen reader behavior for that.
<dandclark> ...If doesn't work, need other minimal role
<masonf> ack sarah
<dandclark> ...That to me is the question on whether it should be moved.
<dandclark> vmpstr: I think that makes sense.
<dandclark> ...I was on the queue to say initially we got kicked from CSS to openui because of a11y. Solution we had was to enforce a button toggling these areas. but we decided we don't need a button, could use other attributes.
<dandclark> ...Eliminated notion of forceful attribute setup. That leans us back to CSS because we decided we don't need button.
<dandclark> ...Don't know about aria roles. One question is i don't know why having an attribute is beneficial to having some css property
<dandclark> sarah: I guess it wouldn't restrict a role. Could restrict the element it'd be on but maybe that's. not desired.
<dandclark> ...My worry is you can't expose actions on a group,, a11y falls down
<dandclark> ...I think it's likely you can. Assuming it has focus when you do overscroll
<keithamus> q+
<dandclark> ...The issue is a AT cursor needs to land on it
<keithamus> ack vmpstr
<dandclark> ...I don't remember if by default your cursor lands on focusable group role if you're not tabbing
<dandclark> ...but screen readers could potentially change that
<dandclark> ...Likely it would work but I need to double check
<dandclark> keithamus: Maybe this speaks to the concern of doing this in CSS. a11y could become fragile depending on how authors express this.
<dandclark> ...If you're allowed to express these properties like a declaration on any element, the element will overried a11y semantics
<dandclark> ...If aria-actions is the one way that users can interact with the overscroll area
<dandclark> ...but the author put it on nav or set role=presentation, that works for mouse users but not AT
<dandclark> ...If we're introducing this in a way that's inherently fragile that's a risk. Maybe that's why we moved to declarative version and why moving to CSS is not entirely straightfowrard.
<dandclark> ...I think it's unprecedented to have declaration that'd only apply to specific elements.
<dandclark> masonf: When you say it's fragile, sounded like it might be possible for devs to do wrong, but not that they can't do it correctly
<dandclark> keithamus: Right. with aria-actions my understanding is it's somewhat invisible.
<dandclark> ...Deeply hidden in devtools to experience it.
<dandclark> masonf: You'll see the buttons
<dandclark> keithamus: If you're declaring them?
<dandclark> masonf: With aria-actions you have buttons that you point to
<sarah> q+
<dandclark> keithamus: But mappings might not take hold
<dandclark> masonf: My understanding of what sarah said is if you add overscroll on an element we enforce a minmal role that's compatible with aria-actions
<dandclark> keithamus: Yes. Concern is if author writes role where role is overridden, might think it works but actually doesn't for screen reader because aria-actions aren't picked up
<dandclark> flackr: Like the dev overwrote it?
<dandclark> masonf: Dev wrote role=foobar
<dandclark> ...We can warn in browser
<keithamus> ack keithamus
<dandclark> vmpstr: Don't understand how attribute makes that better
<dandclark> sarah: I don't think can happen because minimum role will get chosen in conflict resolution
<dandclark> ...Including for focusable things, if dev set role=presentation it'll get thrown out
<dandclark> ...I think that's not the issue. THought of another one, I thought aria-aciotns target was that there'd be guaranteed to be button that does overscroll command
<dandclark> ...If that button doesn't exist, question is, what happens to focus. How does the user know it worked.
<dandclark> ...If the action does scroll directly, how do you confirm it worked
<dandclark> flackr: Same as if user scrolled
<dandclark> masonf: In the email you swipe and see delete button. Aria actions would invoke it without scrolling
<dandclark> sarah: Is it a content bucket or no?
<dandclark> bramus: If you have archive button somewhere, aria-actions points to those available buttons, so when you land by tabbing to email it annoounces what you can do. Those are different from the toggle overscroll button. That button that can toggle overscroll is necessary in interface where you do want button, e.g. in menu case
<dandclark> ...You have button that toggles the overscroll, but nothing else. And aria-actions buttons that give the actions you can do.
<dandclark> sarah: Can only buttons be in the overscroll?
<dandclark> bramus: Can be whatever you want but is ideally some command
<dandclark> ...The thing that is revealed by overscroll can be anything. In menu case it's a nav with links, maybe a close button
<dandclark> ...Doesn't have to be a button
<dandclark> sarah: If the overscroll shows a cat photo, what's the actoinp oint to?
<dandclark> bramus: There's none
<dandclark> sarah: How do you trigger with screen reader?
<dandclark> bramus: Cat photo should be findable in your UI already.
<dandclark> ...The scroll is a shortcut
<dandclark> ...Cat photo in there is probably not good idea
<vmpstr> q?
<vmpstr> q+
<dandclark> keithamus: That's the thing we're trying to prevent, this pit of failure where devs put non actionable items in the menu which is now inaccessible
<dandclark> ...AT user can't activate the overscroll region
<dandclark> ...Almost like you want an always available action to open scroll region and set focus to it
<dandclark> sarah: That was the idea of having the button
<dandclark> keithamus: You're understanding it yeah.
<masonf> q+
<masonf> ack sarah
<dandclark> sarah: Even if you have buttons in the overscroll, how would aria-aciotns point to them if theyre in generic content?
<dandclark> bramus: Aria-actions points to those buttons, you give it the idrefs of the buttons
<dandclark> sarah: Is the browser looking for anything invocable and mapping it?
<dandclark> bramus: Dev needs to map it themselves if they want to expose. In menu case, you don't need to because there's a button for it elsewhere in the UI
<masonf> sbender asks: do aria-actions work for inaccessible nodes?
<dandclark> sarah: I thought by adding overscroll the browser would map aria-actions
<dandclark> bramus: In the proposal I wrote the author does it
<dandclark> ...Browser can't fix the cat photo case.
<dandclark> sarah: That's the issue I'm worried about
<flackr> q+
<dandclark> ...The issue why we have it here not in CSS is because you can have button which aria-acitons points to. If there's no button, aria-actions can't point to anything
<dandclark> ...We could in theory map aria-actions to the overscroll action, but what happens after that?
<masonf> ack vmpstr
<dandclark> vmpstr: The current state of our agreement is we have attributes indicating this is overscroll area and container.
<dandclark> ...Not specifying actions.
<dandclark> If we move to css or stay in this state, don't see how acria-actions convo is differeent.
<dandclark> For cat example, that area would also not be accessible with mouse wheels.
<dandclark> Yes you can build broken UIs generally.
<dandclark> I think that indicates broken in-accessible experiences can be built, but it'd be broken for a lot of users.
<keithamus> q+
<dandclark> No elegant way to prevent that. I don't see how we can solve it or if we should.
<sarah> q+
<dandclark> bramus: And that's the case for HTML or CSS version.
<dandclark> vmpstr: I don't think it's unique to one or the other version
<dandclark> masonf: In actual cat example there'd be a menu.
<dandclark> ...The idea of automatically adding aria-actions to show overscroll might be the best way
<dandclark> ...Avoids the problem of wanting to automatically add actions for everything
<dandclark> ...You want one action, show me the menu
<masonf> ack mason
<dandclark> ...One practical example is the email example, if we add the one action to activate the overscroll maybe it's enough
<masonf> ack flackr
<dandclark> flackr: We discussed previously there's a possibility of automatic aria-aciotn
<dandclark> ...Points to the overscroll area. If it's a container, focus and scroll into veiw. If it's a button, activate the button.
<masonf> ack keith
<dandclark> ...And maybe don't need that action if dev gave a list.
<dandclark> keithamus: A lot of this conversation feels familiar.
<dandclark> ...We talked about the button and said it was bad design. I said then we have to have it because of all these extra modalities, like mouse wheel, overscroll gesture is not easy.
<dandclark> ...We zeroed in on aria actions. sometimes the whole UI is broken.
<dandclark> ...You don't have same swipe gestures on iOS versus desktop. Button forces you to think about this.
<flackr> q?
<dandclark> ...Gets dev thinking about the association, into pit of success
<dandclark> ...Maybe there's solution for AT with aria-aciotns, but doesn't solve for other modalities an impairments.
<masonf> q+
<dandclark> ...If I have motor issues and can't do swipe, it's a failure if I have to fire up AT to trigger gesture to delete email;
<masonf> ack sarah
<dandclark> sarah: +1 to what keithamus said
<bramus> q+
<dandclark> masonf: I am proponent of success but don't know if this feels like one.
<dandclark> ...If I am dev I'll just want to get rid of the button.
<dandclark> ...Better if I build my gmail example, action gets automatically applied, or maybe there's a squiggly line in devtools
<dandclark> ...Forcing the button is a pit of failure
<dandclark> keithamus: If I'm not a screen reader user but can't swipe, what about that interaction?
<sorvell> q+
<dandclark> masonf: Don't know how to enforce, but in practice it happens in gmail today. You have to click the email and the options are available.
<dandclark> vmpstr: Whatever you already do scrolling with might work for this.
<dandclark> sarah: Scrolling with AT is terrible
<masonf> ack mason
<sorvell> Does anyone know how are swipeable actions (like swipe a message to delete) made accessible in native mobile apps?
<masonf> ack bramus
<dandclark> bramus: Want to respond to keithamus. I do see some of the interactions on touch, trying to do them on desktop now like flinging scrollable region.
<dandclark> ...The interactions are bleeding across platforms.
<dandclark> keithamus: There's lots of input modalities. TV remote, playstation controllers, have like 10 buttons and can't swipe
<sorvell> q-
<dandclark> keithamus: Generally everything we put into the web works on most of those devices. Links and buttons work. Even without cursor, can use d-pad to move around focusable areas.
<flackr> q?
<flackr> q+
<sarah> q+
<vmpstr> q+
<dandclark> ...Much like interest invokers we're almost correcting mistakes of devs and designers. building something that's common in designs but is input modality specific.
<vmpstr> q-
<keithamus> ack flackr
<dandclark> flackr: I have to push back on require a button solution.
<dandclark> ...When you go to gmail you don't have 50 focusable delete buttons.
<dandclark> You select the email and then find delete button.
<masonf> q+
<dandclark> ...These overscroll thigns are shortcuts for things you can already do
<dandclark> ...Point bramus is making is the dev supplies another way to do this
<dandclark> bramus: It's like keyboard shortcuts.
<dandclark> ...Great but only available if you have keyboard which is fine.
<dandclark> sarah: Part of me is sympathetic. Also consider Drag and Drop. But feels lower level than this. SOund like we're saying overscroll will be inaccessible by design, but wil be supplemental.
<keithamus> q+
<dandclark> ...Seems different from what conversation was before. Is that what we're saying here?
<dandclark> masonf: I think it's if thers an automatic aria-action to scroll to overscrollable area, that's accessible.
<keithamus> ack sarah
<keithamus> ack masonf
<dandclark> sarah: To screen reader users, not voice control etc.
<bramus> q+
<sarah> +q
<sarah> q-
<sarah> q++
<dandclark> keithamus: What if I just use keyboard. Can tab around today. Niche sounding but all-encompassing examples. Two case where swiping is the intended case, and case where swiping can't be done, are covered; but everything in between is not covered.
<vmpstr> ack sarah?
<Zakim> sarah?, you wanted to react to masonf
<sorvell> It seems lioke if the UI is not part of normal scrolling and the UI in it is inert by default, then it's akin to a popup and it needs a button to activate it or alternate presentation/a11y when not appropriate for the layout.
<vmpstr> ack +
<keithamus> qq+ masonf
<dandclark> sarah: Especially on mobile, it's much more common for people to use switch and voice control. Those can't do aria-actions, need button
<dandclark> masonf: We started this trying to make it automatic, accessible by default.
<dandclark> ...Similar situation with interest invokers.
<dandclark> ...We find that there are use cases where it's bad. Might with this feature have to rely on dev a bit to do the right thing.
<dandclark> ...Button sounded great but we discovrered some input modalities can't use button.
<masonf> ack mason
<Zakim> masonf, you wanted to react to +
<dandclark> ...So want straightforward API where it's easy for dev to do the right thing.
<masonf> ack bramus
<dandclark> bramus: Inverse way to think about this is overscroll limited to touch only devices is limited to that set of users. Overscroll actions with aria-actions can reach more people, even if not all.
<dandclark> gregwhitworth: Can we one-off with the folks passionate about this?
<dandclark> keithamus: Yes. Or can timebox next week as part of regular schedule.
<dandclark> ...And let's take this back to the issue too.
<keithamus> RRSAgent, please make minutes
<keithamus> Zakim, please end meeting

[vmpstr]

Just to respond to a few points:

• For screen reader users, I think we have a solution in that we have an aria-action that opens the overscroll area
• For desktop, I think we have a solution in that the majority population (windows with mouse wheel for example) needs to access these areas, and there are convenient command="toggle-overscroll" things that the developer can set up in those cases
• For mobile users with mobility impairments, I presume that the user is doing focus navigation whether it's with voice or keyboard. In those cases, I propose we make the overscroll container a tab stop and have it respond to the scroll actions in the same way a scroller would respond to scroll actions. I don't know if there are special shortcuts that we can employ here, since scrolling into pull-to-refresh (or scrolling to swipe-to-dismiss) would be somewhat unexpected.

I do want to mention that so far we've talked only about patterns that already exist on the web. I think we can improve accessibility by default for these patterns, and provide easy tools for developers to make the patterns fully accessible.

/cc @keithamus @smhigley @mfreed7 @bramus @flackr

[smhigley]

I think, summarizing from the discussion, the question I'd be interested in folks' thoughts on is: should overscroll be considered a touch-specific interaction with aria-actions broadening that slightly to screen reader users but intentionally not covering access for desktop mouse, voice control, mobility-impaired users, switch, keyboard, etc., or is the goal to automatically enable universal access across all modalities (or as many as possible) by default?

To break down pros/cons (please add any I'm forgetting or that weren't touched on):

touch-specific utility defined in CSS

This (to me) feels similar to drag/drop events in that it's targeted to exposing one specific type of interaction to web authors.

Pros:

• When authors are doing this correctly and overscroll is just one extra affordance to perform otherwise accessible actions, it's easy and they don't need to manually hide or disable browser-added affordances like the additional button.
• It's lighter and more scoped to spec and implement (and therefore also for authors to understand & code for, with fewer side effects)
• It can be in CSS, which allows it to be enabled via media query

Cons:

• It's easy for authors to code only for overscroll + hover/mouse, leaving out keyboard, switch, voice control, etc. Think something similar to GMail's archive/delete/mark read actions that work with overscroll on mobile, and show on hover on desktop. A company that does less accessibility testing seems (in my cynical view) likely to leave it at hover/overscroll and forget the rest.

These weren't discussed in the call, but occurred to me afterward and are more specific to CSS vs. HTML and not related to touch-only vs. broadly accessible:

• If authors do want do wire up a button with a command to overscroll, having the overscroll element defined in CSS separates where the definition & button association happen, making it less convenient to author and maintain:

<li id="message-item">
  <div class="primary-content">
    Sender: Hello world!
  </div>
  <menubar id="message-actions">
    <menuitem>Archive</menuitem>
    <menuitem>Delete</menuitem>
  </menubar>
  <button commandfor="message-item" command="toggle-overscroll">
</li>

/* what happens if someone moves this style to a different selector? */
.message-list li {
  overscroll: light;
}

• There are a number of interactive behaviors (dismiss interactions, modal vs. non-modal) that are part of overscroll and relevant when authoring JS to handle the related events. These are much easier to query in JS if defined in HTML.

broadly accessible feature defined in HTML

Pros:

• Most authors don't think about accessibility beyond the basics, especially not voice control / switch / mobility impairments affecting scroll interactions / etc., and those would be the ones particularly impacted by not having a separate button to invoke.
• Rendering a button out of the box in theory would get authors to at least question why it's there before hiding it, and force some amount of intentionality if they truly have a use case where they do not need the button (acknowledging this can be annoying though)
• Things that affect interactivity are just easier to debug when defined in HTML -- you can target them with a JS querySelector, find them in devtools faster, etc.

Cons:

• Harder to enable this feature based on screen size or touch support, whereas CSS allows this easily via media queries
• If the browser renders or forces you to define a button to make this work, it's an extra step to hide it when you genuinely don't need it. I'm not sure the balance of how many implementations need the button to be accessible vs. how many don't. Email is a good example of not needing it, since users can perform the same actions after opening the email.

Other options

We could consider explicitly saying this is a touch specific utility, but still keep it defined in HTML, based on the other pros & cons specific to CSS.

I'm also curious what folks would think of keeping the HTML approach but adding an associated CSS property to disable the overscroll behavior. That would keep all the authoring benefits of HTML while also adding the ease of enabling it based on a media query.