Get Weekly Digests pattern

[gerardo-rodriguez]

This task is a continuation of #1508 where the Button Swap pattern was introduced for the "Get Notifications"/"Turn Off Notifications" UI interactions.

This task focuses on the "Get Weekly Digests" UI interactions which reveals a subscription form.

[gerardo-rodriguez]

@Paul-Hebert @tylersticka I thought at one point there was a conversation of whether the "Get Weekly Digests" pattern was also going to be used in the header section of the page. Or do we need a separate task for that? I'm not sure. 🤔

[Paul-Hebert]

I'm also not sure. My gut feeling is that the entire form should always be shown in the header section.

So maybe the form that is exposed by clicking "Get Weekly Digests" is the same in both places? Or maybe the form is the same markup with a modifier class to slightly adjust layout?

I'm not sure... open to ideas!

[tylersticka]

In a perfect world, I think it would be cool if the same notification UI (including both push notifications and weekly digests) could be used in either location. The benefits of this would be...

• Greater prominence of the push notification option (and our ability to implement such a feature)
• Easier to unsubscribe for those returning
• Consistency of experience across pages

Potential drawbacks would be...

• Necessity to make the pattern work in light and dark themes
• Greater visual complexity in header area

I think the pros outweigh the cons, but that may change as we learn more.

[Paul-Hebert]

Yeah that makes sense to me 👍

[gerardo-rodriguez]

Possible resource: https://adrianroselli.com/2020/05/disclosure-widgets.html

[gerardo-rodriguez]

For reference, here is the existing UX:

1. Click "Get Weekly Digests"

   • Hides "Get Weekly Digests" button
   • Reveals a subscription form

2. Once the subscription form input loses focus

   • The form is hidden after a delay
   • The original "Get Weekly Digests" button is revealed

Possible resource: https://adrianroselli.com/2020/05/disclosure-widgets.html

I was misremembering what the UX was for this UI, I don't think it follows the Disclosure Widget pattern.

[gerardo-rodriguez]

I've been doing more research trying to figure out how to implement this pattern in an accessibe fashion. I also reached out to the web-a11y.slack.com community.

Trouble finding accessible UI patterns

I have been unable to find an accessible UI pattern that matches our design. The closest two I found were:

• disclosure widget
• progressive disclosure

Neither one is a match, though. In neither pattern does the button go away as the content reveals.

a11y Slack concerns

The feedback I was getting from the a11y Slack community quickly turned into, "yikes, you should consider redesigning the experience as there are red flags with the current design" types of feedback.

Concerns included:

I think what’s not clear to me in this design is how to back out of this if you pressed the button by accident.

what happens after you hit the subscribe button? does the field go away? do you return to the previous UI? is there a confirmation message instead?

hmmm that seems confusing, and I feel like the screen reader experience would be particularly jarring. There may be some announcements and information you could provide to help orient users to the change, but that may also be noisy/confusing.

A fixed timeout on blur sticks out to me. Does it run afoul of 2.2.1? Losing what you took the trouble to type can be pretty painful. What if you accidentally hit TAB from the input twice instead of once, and didn't SHIFT +TAB back quickly enough? I'm guessing what you typed is lost?

I pointed out you back out by blurring out of the form, after a short delay, the form disappears and the buttons come back. I also mentioned that if you accidentally blur out of the form, what you typed is not lost, though, you do have to hit the button to reveal the form again since it will have disappeared most likely. To "what happens after you hit subscribe"? A new browser tab is opened to a MailChip confirmation page:

a11y Slack suggesting a redesign

Having the content expand with a disclosure pattern or even opening a modal that lets you either fill out info or cancel out of it seems like a better option here than replacing the content.

Sorry I don’t have a better suggestion than I think the design should probably change

Summary

I can easily reimplement the existing design as-is, but I feel I have a responsibility to point out that it is not an inclusive UX and cannot be made accessible in its current design. I can try to implement something similar to a disclosure widget or progressive disclosure but since our pattern is different, it won't match up exactly and may actually provide a worse assistive technology experience.

@cloudfour/design I'm curious what your thoughts are? Does it make sense for me to reimplement the existing UI/UX knowing it is not accessible (I'd rather not as it doesn't align with Cloud Four’s core values)? Or do we explore a different design? Thanks in advance for your feedback!

[tylersticka]

@gerardo-rodriguez I'm getting a bit of dejá vu reading this thread! I'm going to spend some time whipping up a CodePen for what I thought we agreed on last time but did not document very well. Then we can circle back on what will or won't work.

[tylersticka]

@gerardo-rodriguez Just to recap, last time these concerns were raised we all got together and had a sketching session to figure out alternatives. Several participants walked away from that session with low enthusiasm for the alternatives, for a few reasons:

• Many of the alternatives seemed to suggest that users would want to sign up for both options. We believe this will be very infrequent.
• Some alternatives resulted in a UI that was much more visually complex, appearing as a set of tabs or a longer form. It felt off to take something straightforward and make it more complicated: It seemed strange that it would be impossible to better represent the more straightforward presentation in an accessible way.
• Many ideas (such as those involving modal dialogs) often required more clicks to accomplish the same action, or additional clicks to get back to the blog content (which seemed especially unnecessary since, as mentioned, we think users are most likely to make their choice and move on).

My recollection is that one of the sketches seemed only cosmetically different from what we already had. I remember meeting with you to discuss that, and I believe you acknowledged that we may have been thinking of the buttons too literally as accordion-like toggles.

I've attempted a quick-and-dirty CodePen example of where I thought we landed at that time: https://codepen.io/tylersticka/pen/WNdQZwW/cdfff8c07c8c14c6a91fc6de4c1ef917

Some notes:

• Elements are only ever hidden visually: They are still always accessible via focus or the screen reader.
• The visibility timeout is skipped entirely when visually hidden elements are given focus.
• One point of consideration: This is a very specific and contextual sort of interaction. It's arguable whether or not it deserves to be a pattern or if it should just be part of our theme.

Let me know if you'd like to discuss with voices!

[gerardo-rodriguez]

Thanks, @tylersticka!

I'm getting a bit of dejá vu reading this thread!

Same! LOL 😅

Just to recap, last time these concerns were raised we all got together and had a sketching session to figure out alternatives.

I remember the sketching session as well! Although, now I'm unsure if we are speaking about the same sketching session. The sketching session I recall was for the "Get Notifications" UI/UX (I don't have a recollection of a sketching session for the "Get Weekly Digest" UI/UX).

I remember meeting with you to discuss that, and I believe you acknowledged that we may have been thinking of the buttons too literally as accordion-like toggles.

Yep, I remember this as well! 🎉 Although, from my perspective, the focus was the "Get Notifications" button and not the "Get Weekly Digest" UI/UX. 🔍 👀 🤔

I've attempted a quick-and-dirty CodePen example of where I thought we landed at that time: https://codepen.io/tylersticka/pen/WNdQZwW/cdfff8c07c8c14c6a91fc6de4c1ef917

Thanks for the Codepen! @calebeby and I previously explored a couple of ideas for the "Get Notifications" UX but I don't have recollection of exploration for the "Get Weekly Digest" button so this is very helpful, thank you.

Elements are only ever hidden visually: They are still always accessible via focus or the screen reader.

This is excellent, I started floating this idea in my head overnight, so I'm glad we both feel the same. 🎉 😄

The visibility timeout is skipped entirely when visually hidden elements are given focus.

This matches what is currently implemented, so that's good, no changes there. 👍

One point of consideration: This is a very specific and contextual sort of interaction. It's arguable whether or not it deserves to be a pattern or if it should just be part of our theme.

Hmm...good point. I totally get what you are saying, though, I hadn't considered not making this a pattern. I was under the impression that this was a one-time use type of pattern for a very specific use-case. That being said, since there was conversation about the pattern possibly existing in multiple locations, I figured might as well make it a pattern we can drop in wherever we need it. I've already started building out within the cloudfour.com-patterns repo (still WIP), it felt most comfortable for me to develop there.

Let me know if you'd like to discuss with voices!

I'm not sure what's outstanding at the moment.

I think the new takeaway for me is that the form is visually hidden but accessible via :focus as the most likely solution (per your Codepen). I think this alleviates most of the concerns regarding trying to make sure it's accessible as possible, though I'll make sure to bubble any new concerns up as I think about them. 👍

Thanks for your feedback! 😃