A deep dive into Accessible Notifications

Acknowledgement of Country

I'd like to start by acknowledging the Traditional Owners of the lands on which I am recording this video.

In my case, this is the Cammeraygal people of the Eora Nation.

I also pay my respects to Elders past and present, and extend that respect to all First Nations people who are attending this event.

What are notifications?

Notifications are aspects of the user interface that bring something to the attention of user.

They are an important part of almost all digital products.

When they are well designed, notifications help improve the user experience.

When they are poorly designed, notifications can be distracting, annoying or frustrating!

Types of notications

We're going to look at notifications that are grouped based on the level of attention they require from users.

Level 1: Immediate attention and user action

The first level of notification require immediate attention and user action.

Level 2: Attention at specific times

The second level of notfications require attention from the user at specific times after some event.

Level 3: Do not require urgent attention

The third level of notifications are designed to inform users of an event, but do not require urgent attention.

Level 4: Related to user interaction

The fourth level of notifications are directly related to user interaction on an element - and so only require attention at that time.

Level 5: Discoverable

And there are notifications that require the lowest level of attention as they are purely discoverable.

Different names or categories?

This is just one way to classify some common types of notification.

You may have different names for them.

You may also categorise them slightly differently.

Lots of different types.
They have different user needs.
Some are more important than others.

General considerations

What type of information is being communicated?
What is the urgency of the information?
Are user actions needed?

What actions will trigger it?
Where will it appear?
How will it appear?
Is it time-based or dismissable?

People who depend on accessible notifications

First off, lets look at some types of people who depend on accesible notifications.

People with some cognitive and learning disabilities, who may be easily confused by unexpected behavior and unclear error messages.

People with partial or no sight, who rely on notifications, instructions, and errors messages to understand the context and interactions.

This second group may include users of screen readers, refreshable braille devices or screen magnification software.

1. People with some cognitive and learning disabilities.

2. People with partial or no sight.

Accessibility considerations

Users need to know what's going on
Users need to get appropriate feedback
Clear directions for errors
Attention at the appropriate time

At the most fundamental level, all users need to know what is going on, and get appropriate feedback during interaction.

Error messages must provide clear directions rather than confuse users.

One of the biggest challenges with notications is deciding when to draw attention to something.

If information is shared too often or at inappropriate times, the experience could be frustrating.

If information is shared too little, users may miss critical information.

Accessibility considerations for designers

Does it need to be dismissable?
Does it need to recieve focus?
If so, where does focus go after it is dismissed?

Does it use colour alone for meaning?
Does it have sufficient colour contrast?
Does it contain animation/flashing that can these be turned off by users?

Accessibility considerations for developers

Does it have an accessible name?
Does it need a role or live regions?

Does it need to be announced to assistive technologies?
If so, what is the appropriate time?

Are keystrokes needed within it?
Can all actions be undertaken using keyboard only?
Does it need to trap some keystrokes?

Ideally, designers and developers should collaborate to make key decisions.

Toast notifications

Inform users of a successful action
At the bottom of the viewport
Often time-based
Do not require user action

Toast notifications are often used to inform users of some sort of successful action.

They often appear in the bottom of the viewport, animating up into view.

They're often time-based, so will only appear on screen for a short time period.

They normally do not require user action.

If user-intaction is needed, it should probably be a Push or Growl notification.

What about Toast notification accessibility?

Let's assume that you decide it is important to let users know that something has been successfully completed.

And you decide that a toast popup is the best solution as it lets users know without interfering with their overall processes.

This means that you have decided that sighted users will be presented with tangental information to let them know of the successful action.

If you feel that this information is important enough to present to sighted users, you must do the same for non-sighted users.

So, any Toast notification information needs to be announced to screen reader users.

Let's assume you decide that a toast popup is the best solution.

You must make these notifications accessible to non-sighted users.

The announcement should be polite rather than interrupting the current process - just like for sighted users.

We could use aria-live="polite", as this will announce the notification at the next graceful opportunity.

<div aria-live="polite">
  ...
</div>

Or could use a role, such as role="status".

<div role="status">
  ...
</div>

This role has implicit aria-live="polite" and aria-atomic="true"

The aria-atomic attribute indicates whether assistive technologies will announce all or only parts of the changed region.

The true attribute will announce the region as a whole when changes are detected - everything within the region

There should be no need to send focus to a Toast notification as it should not contain important user actions.

The notification should appear in close proximity to the user's action.

This is especially important for ZoomText users, who may have some sort of screen magnification in place.

If the toast appears in a completely different area of the screen, these users may miss the notification entirely.

Push notifications

Inform users of something important
Need attention and user action
Anywhere within the viewport
Not time-based

Push notifications are often used to inform users of something important.

For this reason, they often need attention and user action.

They could appear anywhere within the viewport.

As there is always at least one user action they should not be time-based.

So, users must engage with the notification, even just to dismiss it.

What about Push notification accessibility?

Due to their importance, push notifications need to receive user focus.

Focus could go to the notification container.

<div tabindex="-1">
  ...
</div>

Or the main heading inside the notification.

<div>
  <h3 tabindex="-1">Notification heading</h3>
</div>

Or the first focusable element inside the notification.

<div>
  <h3>Notification heading</h3>
  <button></button>
</div>

As the push notification is going to receive focus, it will need an accessible name.

This could be applied directly to the notification container using an aria-label.

<div aria-label="Something">
  ...
</div>

Or the heading inside could be used to give the overall container a name.

This could be achieved by applying an aria-labelledby to the overall container, and a matching id to the heading.

<div aria-labelledby="aaa">
  <h3 id="aaa">Notification heading</h3>
</div>

Also due to their importance, push notifications needs to be announced immediately.

We could use aria-live="assertive", as this will announce the notification immediately.

<div aria-live="assertive">
  ...
</div>

Or could use a role, such as role="alert".

<div role="alert">
  ...
</div>

This role has implicit aria-live="assertive" and aria-atomic="true"

The notification needs to be accessible using the keyboard-only.

This means you should not have to use the mouse or trackpad to do any interactions with the notification.

If dismissed by the user, you need to decide the most intuitive place to send focus.

Ideally, this would be their previous location before interacting with the push notification.

If that isn't possible, you may need to send users to the main content area of the page.

<main>
  ...
</main>

You need to send them somewhere that is intuitive and helpful.

Modals

Deliberately interrupt user flows
Over the top of the overall UI
At least one user action

Modals are designed to deliberately interrupt user flows in order to solve an immediate problem.

When the problem has been resolved or dismissed, users should be taken back to where they were before the interruption.

Modals generally appear over the top of the overall UI, and the content below is dimmed.

There is always at least one user action associated with the notification.

As with push notifications, users must engage with the notification, even just to dismiss it.

What about modal accessibility?

Almost all of the same things apply here as with push notifications.

There are some key decisions around where focus should be sent with the modal is triggered.

Should focus go to the modal container, the heading or the first focusable item?

The answer may depend on the content or purpose of the modal.

Keyboard activity should remain focussed on the modal until at least one user action has taken place.

This means that while the modal is open, keyboard users should never be allowed to interact with the page below.

So, keystrokes such as TAB and SHIFT + TAB need to "trap" focus within the modal.

Unless we want to allow users access to the browser Chrome - address bar etc.

And like push notifications, you need to decide the most intuitive place to send focus once the modal has been dismissed.

Generally, this would be the element that triggered the modal, such as the button.

However, in some cases you may want to take users to a different location, such as drawing attention to a change in content.

Form field error notifications

Visually “flagged”
No use of colour-alone
Close proximity
Informative error message
Programmatically associated
Defined as invalid

1. Each form field that has errors should be visually “flagged” to show that they are invalid.

2. The “flagging” method should not use colour alone to signify that the form control is invalid.

3. An error message should be positioned in close proximity to the form field that is invalid.

4. The error message should be informative - it should provide information that will help users fill in the field correctly.

5. The error message must be programmatically associated with the invalid form field.

This means that the error message will be announced along with the label when the form control is in focus.

This can be achieved using matching aria-describedby applied to the form control and a matching ID applied to the error message.

<label for="name">Name</label>
<input
  type="text"
  id="name"
  aria-describedby="aaa"
>
<span id="aaa">Error message</span>

6. The invalid form field should be set with aria-invalid="true".

This informs assistive technologies that the value entered does not conform to the format expected by the application.

<label for="name">Name</label>
<input
  type="text"
  id="name"
  aria-describedby="aaa"
  aria-invalid="true"
>
<span id="aaa">Error message</span>

On-submit error notifications

There are two fundamental approaches to error notification.

On-blur
On-submit

On-blur

The first approach involves validating and notifying users of errors as focus leaves each individual form field, often referred to as onBlur.

As focus leaves each form field, users should be notified if the field is in a state of error.

On-submit

The second approach involves validation and notifying users of errors as they attempt to submit the form, often referred to as onSubmit.

After the submit button is activated, users should be notified of all fields that are in a state of error.

In reality, forms that use onBlur for form field validation must still use onSubmit validation as well.

The reason is that users may not resolve individual form field errors before attempting to submit the form.

Let's look at a situation where a user tries to submit a form which has two invalid fields.

An accessible on-submit error notification

1. The error notification container must be placed above the form.

<div class="error-notification">
</div>
<form>
</form>

2. Focus should be sent to the heading inside the notification container.

<div class="error-notification">
  <h4>
    Please fix the following two errors
  </h4>
</div>

3. The heading should be set with tabindex="-1".

This means that this heading will initially receive focus as soon as it is triggered, but then remain out of tabindex order afterwards.

<div class="error-notification">
  <h4 tabindex="-1">
    Please fix the following two errors
  </h4>
</div>

4. The error notification should list all errors, allowing users to jump to the relevant form errors.

The lists could be the label content, error message content or a combination of both - as long as it is helpful to users.

<div class="error-notification">
  <h4 tabindex="-1">
    Please fix the following two errors
  </h4>
  <ul>
    <li><a href="#">You must include...</a></li>
    <li><a href="#">You must use a...</a></li>
  </ul>
</div>

Wrap up

Notifications should considered carefully - especially from accessibility perspective.

If you are designing notifications, you need to consider exactly how users can and should engage with notifications.

And, you need to consider how and when these notifications are presented to different users.

Good luck with all of your future notifications.