Taming the messaging chaos

purple = incomplete thoughts

@Adam Butterworth (Deactivated) Thoughts?

Messaging UI is currently a bit of a mess, and uncoordinated between business areas. Example:

Discovery:

Open

Open

Course Home:

Course Learning Unit:

[adopt @Eugene Kang 's new design here?]

Specific Issues that May Be Addressed Here

Key differences in UI today could be made more consistent in presentation:

• Location

  • Most pages:

    • Above header?

    • Below header?

    • Above the footer (toast)?

  • Course outline page:

    • Above outline

    • Right sidebar?

  • ??

    • Toasts

• Dismissible?

  • Close button style?

• Color scheme used for different message types (semantics and locations)

  • Inline link styling also differs within message types

• Icon sizes

  • Icons enclosed in message rectangle, or can overwrite the edges?

• Vertical spacing is a bit variable

• Widths are variable

  • Not following header or main body margins

I note that all of those minor visual design issues exist, but there is also a need for coordination of messaging UI and page structure for blind and low-vision learners.

Primary Objective / Suggestion

To tame the messaging chaos, the core of my proposal is that all transient messages should be presented through a unified messaging mechanism (API and/or React object model) within the Paragon design system. Users of this API or object model would pick a message type, location, and body text (possibly with inline links), and Paragon will take care of presenting it properly along with any other messages that are pertinent.

Suggestions for unification of visual UI

1. [@Jeff Witt (Deactivated) is not intending to address these issues. @Ange Romanska (Deactivated)?]

2. [visual homogenization tweaks, if not already covered in Paragon messages]

3.  

A11y-related UX considerations

User scenarios

Blind user

— needs to “bump into” messages currently

Semantic structure

Noticeability

Low-vision user

Noticeability

Completeness

User has speed-of-reaction issues (dexterity, mobility, cognitive)

Use of timers, where a message appears and then disappears after some number of seconds, presents accessibility issues. What if the learner didn’t notice the message while it was up? What if they were not able to respond in time (they may be a mouse/trackball user, but move very slowly). If they’re a keyboard-only user, will they be able to tab or jump to the message before it disappears? It’s best not to use timers at all, but if it makes sense to use timers, there should be a way to get back to the message that disappeared to soon.

Proposed Page Structure

This structure introduces no new visual elements, but only semantic containers. Some regularization of the visual appearance of different message types within the container is assumed.

We add an invisible summary of the number of messages at the top of the <header>, and some additional skip links to jump to the relevant message clusters. We move the regular SkipNav link to after the new skip-to-messages links in order to force blind learners to notice the first skip-to-messages links (if they exist).

<header>

</header>

We add a <section> at the top of <main>, and some list structures to hold the messages. These list structures have no visual affordances; they’re just for screen reader users.

<main aria-label=“contents”>

<aside>

</aside>

Key ARIA Usage Issues

A key thing to understand is that the canonical method of alerting a user with ARIA assumes that there is only one message at a time, even though that just isn’t the case in a lot of scenarios. A regular <div role=”alert”> has an implied aria-live=”assertive”, which means the alert will interrupt any other speech output that was happening (“flush the speech queue”) when the alert appears. This is effective as long as there is only one alert present. If more than one alert appears (say, after Submitting a form), the downstream alerts will immediately interrupt upstream ones. So in effect a blind person will only hear the alert that was drawn last.

Another approach to dealing with the stack-of-alerts problem might be to add aria-live=”polite” to each one. But then the user hears a big stack of messages when they first come to the page, and they won’t know how many total messages are there.

Also today a blind learner can’t really skip through the list easily because they’re scattered on the page.

There is also a noticeability issue for notes (<div role=”note”>). Normally a note has an implied aria-live=”off”, which is probably appropriate, assuming the user would bump into that note in some other way. But is that a good assumption?

The key difference with this method, in terms of blind-user experience, is that we will rely on the single <div role=”status” aria-live=”polite”> at the top of the page in order to get the user’s attention for all messages.

Other Considerations

• Is it possible to anchor toasts in the proposed top-of-page list structure yet still show them at the bottom of the viewport? I assume so.

• What role is a status update? We could conceivably have more roles in Paragon and map them to the smaller number of roles given by ARIA. Possible roles:

  • Message (role=”note”)

  • Opt-in legal notification (role=”dialog” aria-modal=”false”)

  • Status update (role=”status”)

  • Reminder (role=”alert”)

  • Error message (role=”alert”)

• I’m suggesting changing the regular SkipNav link in the header to jump to an <a> target inside the <main> instead of directly to the <main>. This is consistent with a WCAG 2.1 -style stricter interpretation of only allowing focus to land on things that are intended to take focus.

• How urgent should legal disclosures be? Variable?

Messages in context

On blur vs. on submit

Messages referring to relevant downstream items

With links?

Related articles