eBay

Inline Notice

Highest bidder notice

Introduction

A user notification that appears next to a region or control.

An inline notice is typically classified as either high or low priority. An error that prevents an action or task is high-priority, whilst most other types of notice are low priority. Low priority notices are typically informational in tone.

Composite patterns containing Inline Notice are:


Working Examples

You can take a look at the inline notice pattern in action on our examples site.

For a real world example, you can also see the pattern in action over on eBay Skin.


Best Practices

Avoid having more than one high-priority notice visible at any time.

Avoid rendering high-priority inline notices on the server. Use a page notice instead. If you cannot use a page notice, then focus must be set on the inline focus.

Avoid using progress bars and spinners in conjunction with client-side notice.

A notice for a success confirmation may not always be necessary.


Interaction Design

Keyboard

Must be possible to TAB to nested interactive elements in a logical and linear order.

Screen Reader

Screen reader does not need to announce low-priority server side notices.

Screen reader must announce client-side content changes to notice.

Screen reader must announce client-side visibility change of hidden notice.

Screen reader should announce element notice when related interactive element gains focus.


Developer Guide

Our implementation follows the Progressive Enhancement strategy. We build in a layered fashion that allows everyone to access the basic content and functionality of a web page.

The three layers are:

  1. Content (HTML)
  2. Presentation (CSS)
  3. Behaviour (JS)

For our example, we are going to mock up an implementation based on a typical 'Like' button you might find on any web site these days. This like button will emit a high-priority notice when any error occurs.

Content (HTML)

Let's make it work on the server first, without any JavaScript.

Form

We'll need a form, a hidden form value, and a submit button:

<form id="likeForm">
    <input name="like" type="hidden" value="iphone12345" />
    <input type="submit" value="Like" />
</form>

Clicking this button will submit the form. When the page reloads our item will either be 'liked' or an error message will appear.

At this stage, without JavaScript, the error message must be a server-side page notice, not an inline notice. Refer to the page notice developer guide for details. Our inline notice is a progressive enhancement of this baseline, server-side experience.

Structure

To add hooks for progressive enhancement, we wrap the submit button inside of a div. Then we append a live region to contain our client side message.

<form id="likeForm">
    <input name="like" type="hidden" value="iphone12345" />
    <div class="elementnotice" id="elementnotice-1">
        <input aria-describedby="elementnotice-1-msg" type="submit" value="Like" />
        <div aria-live="polite" id="elementnotice-1-msg">
            <!-- message text goes here -->
        </div>
    </div>
</form>

You may want to create this structure on the client, during an initialisation routine, rather than on the server.

Presentation (CSS)

You can style the button and inline notice according to your design system guide.

Remember to toggle the display property of the live region contents, not the live region itself.

.elementnotice-js [aria-live] p {
    display: block;
}

VoiceOver will detect the sub-tree visibility change and notify the user accordingly.

Behaviour (JS)

The goal of JavaScript is to:

  1. Prevent the form submit action
  2. Perform the service call using AJAX
  3. Display any error message next to our button

Step 3 is of interest to us. We must ensure the error message is accessible.

Display Message

Assuming there was an error, we update the live region content:

$('.elementnotice [aria-live]').append('<p>There was an error! Please try again.</p>');

"There was an error! Please try again." is the message displayed on screen and announced by the screen reader. Keyboard focus remains on the button.

Button Description

If the user tabs away from the button, and then tabs back, it would be nice to remind the user of any error message. We can achieve this with the aria-describedby property:

$('.inlinenotice > input[type=button]').attr('aria-describedby', 'elementnotice-1-msg');

Remember to assign a unique id to the live region for this to work.


FAQ

When do I use role=region on an inline notice?

For notices rendered once on the server and visible at page load time.

When do I use role=alert on an inline notice?

For all notices rendered on the client. Or for notices rendered once on the server that will later be updated by the client.

When do I set keyboard focus on an inline notice?

Always set keyboard focus on high priority notices rendered by the server and visible at page load time. Again, these situations should be rare. Use a page notice instead.

For notices that contain long messages with structured or interactive elements. For example, an error notice displayed by client-side form validation.

results matching ""

    No results matching ""