Accessible chat windows

I’m going to provide you with some
things to consider if you’re trying
to build an accessible chat window.

However, before we dive into chat
windows I’d like to de
fi
ne three
concepts, just to avoid confusion.

The three concepts are:
1. Modal dialogues
2. Pop-up noti
fi
cations
3. Chat windows

Modal dialogues are functions that
are designed to interrupt a user
fl
ow.

They require the user to perform a
speci
fi
c action before proceeding
with the user
fl
ow.

Generally, modal dialogues are
separate “windows” positioned
over the top of the parent page.

Are you sure you want to delete this
fi
le?
You cannot undo this action.
Delete
Cancel
Greyed out background

fi
le?
Delete
Cancel
Modal container

fi
le?
Delete
Cancel
Close button

fi
le?
Delete
Cancel
Modal content

fi
le?
Delete
Cancel Action buttons

Pop-up noti
fi
cations communicate
speci
fi
c events to the user without
forcing them to perform any
action.

Pop-up noti
fi
cations can appear
anywhere within the overall
layout of the page.

For example, Toast noti
fi
cations
often “pop up” at the bottom of
the screen.

A success toast
An information toast
A warning toast
An error toast
Toast pop-ups in bottom right corner

A success toast
A warning toast
An error toast
A “Success” toast

A success toast
A warning toast
An error toast
An “Information” toast

A success toast
A warning toast
An error toast
A “Warning” toast

A success toast
A warning toast
An error toast
An “Error” toast

A success toast
A warning toast
An error toast
Optional close buttons

“Chat windows” or “chatbots” are
UI components that allow users to
engage with an operator or
arti
fi
cial intelligence.

Unlike modal dialogues, the aim of
chat windows is not to force users
to complete an action before
continuing.

Chat windows provide personal
assistance to users at speci
fi
c
times within the user’s journey.

This assistance could include
answering a question or helping
the user complete a task.

Common features of
chat windows

When opened, chat windows are
commonly positioned in the
bottom right corner of the screen.

Most chat windows include
functionality such as:

Welcome to live chat
Type your message here…
Chat window
Hi!
How may I help you?
Can I ask about costs?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Message:

Chat title
Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Message:

Hi!
How may I help you?
Close button
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Message:

Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Optional collapse button
Message:

Conversation window
Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Message:

Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Operator name and time
Operator messages
Message:

Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm User name and time
User message
Message:

Form label
Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Message:

Form input
Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Message:

Type your message here… Submit button
Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Message:

Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Optional add attachments
Message:

Some chat windows include login
forms within the chat window.

Name:
Title:
Email:
Chat window with form

Auto vs manual
triggering chat
windows

Chat windows can be triggered in
two ways:
• manually by the user
• automatically based on speci
fi
c
events.

Automatically triggered chat
windows could interrupt the
user's current process.

This is especially important for
some neurodiverse users, where
visual distractions can cause a
signi
fi
cant loss of concentration.

Ideally, chat windows should allow
users to determine when and if
they want to engage with the
function.

Elements for
triggering a chat
window

The <button> element should be
used to trigger the opening of chat
windows.

These <button> elements are
often placed in the bottom right
corner of the screen.

Chat with us
Chat window trigger

And they are also often placed
towards the very end of the page’s
source order.

...
</section>
</div>
</div>
<button>Chat with us</button>
<script src="https://cdnjs.cloudflare.com/ajax/libs/
headjs/1.0.3/head.min.js"></script>
<script src="dist/something.js"></script>
<script src=“plugin/notes/another.js"></script>
</body>
</html

As we’ll see, the visual position and
the position in source order can
impact some users.

We’ll now look at how chat
windows can affect four different
people.

These example user pro
fi
les are
taken from the Gov.UK disabilities
and impairments user pro
fi
les.
https://www.gov.uk/government/publications/
understanding-disabilities-and-impairments-user-pro
fi
les

Claudia is a person who is partially
sighted. She uses a screen magni
fi
er
so that she can enlarge the overall
display.

Claudia has her magni
fi
cation set to
an extreme setting, which means she
can only see a small section of the
screen at a time.

Problem 1:
If Claudia triggers the <button> and
focus doesn’t shift to the chat
window, she may not be aware that
the chat window has been activated.

Problem 2:
Claudia may not see messages from
the operator if actions take place
off-screen.

Things to consider:
For Claudia, proximity is the key. If
she triggers an action, the result
should appear in close proximity to
the trigger.

Christopher is a person with
rheumatoid arthritis. He prefers to
use a keyboard to avoid mouse
movements which can impact his
condition.

Problem 1:
If the <button> is one of the last
items in tabindex order, it may take
many keystrokes for Christoper to
navigate to this element.

Problem 2:
If focus doesn’t shift from the
<button> to the chat window when
it has been triggered, Christopher
may not be able to interact with the
chat window at all.

Problem 3:
If interactive functions within the
chat window are not accessible via
keystrokes, Christopher will not be
able to interact with them.

Things to consider 1:
Christopher should be able to bypass
blocks of content to access the chat
window trigger.

All interactive elements in the chat
window must be completely
keyboard accessible without a
mouse.

Focus must be visible on every
focusable element so that
Christopher can track what is
currently in focus.

Ashleigh is a person who is legally
blind. She uses a screen reader to
navigate websites.

Ashleigh is also a keyboard-only
user, as she does not use a mouse. So,
many of the issues mentioned for
Christopher also apply to Ashleigh.

Problem 1:
Ashleigh needs to know that the page
contains a chat function. Otherwise,
she may not even know that it exists.

Problem 2:
The purpose of the <button> needs
to be clearly de
fi
ned. For example, if
it just says “Chat”, this may not
provide enough context for Ashleigh.

Problem 3:
When focus shifts to the chat
window, Ashleigh may not know
what has happened. All she knows is
that focus has shifted somewhere
else on the page.

Problem 4:
If interactive elements within the
chat window don’t have clear labels,
Ashleigh may not understand their
purpose.

Problem 5:
If the operator submitting a new
message, Ashleigh may not be
informed that this has occurred.

Problem 6:
If Ashleigh closes the chat window
and focus does not return to the
<button>, Ashleigh may become
disorientated within the overall page.

Ashleigh should be informed that the
page contains a chat function. And
she should be able to bypass blocks
of content to access the chat
window trigger.

The <button> needs to have a label
that is meaningful for Ashleigh.

When the chat window receives
focus, its name and role need to be
announced so that Ashleigh
understands its purpose.

All interactive elements needs to
have clear labels so that Ashleigh
understands their purpose.

Ashleigh needs to be informed about
all dynamic changes within the chat
window - such as newly added
messages from the operator.

When the chat window is closed,
focus needs to return to the
<button> so Ashleigh can orientate
herself within the overall page.

Simone is a person with Dyslexia.
She has dif
fi
culty reading large blocks
of content.

Simone also has spelling issues,
especially when typing information
into the chat window.

Problem 1:
If Simone misspells one or more
words, this may confuse the operator
or the arti
fi
cial intelligence.

Problem 2:
Abbreviations and acronyms may
confuse Simone, especially if she
feels stressed due to time
constraints.

Things to consider:
• use plain language
• avoid acronyms
• use short sentences/paragraphs

There are many ways to mark up a
chat window depending on the
types of functionality needed.

But let’s take our previous
example and look at some possible
HTML markup.

Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Message:

The overall container can be given
a class name of "chat".

Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Message:
"chat"

The container for the heading and
“Close” button can be given a class
name of "chat-header".

Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Message:
"chat-header"

The container for the messages
can be given a class name of
"chat-content".

Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Message:
"chat-content"

The container for the label, user
input and submit button can be
given a class name of "chat-
submission".

Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Message:
"chat-submission"

“chat” and
“chat-header”

The overall container needs to be
given a role so that assistive
technology users understand its
purpose.

As there is no speci
fi
c role for
chat windows, we could use
role="group".

Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Message:
role="group"

This overall container also needs
to receive focus which can be
achieved using tabindex="0".

It also needs to be given an
accessible name that will be
announced to assistive
technologies.

We can use aria-labelledby on
the container and a matching id
on the heading.

<div class="chat" role="group" tabindex="0" aria-
labelledby="a1">
<h3 id="a1">Welcome to live chat</h3>
</div>
</div>
</div>
</div>

The “Close” function should be a
<button> element - ideally with a
visible text label saying “Close”.

labelledby="a1">
<button>Close</button>
</div>
</div>
</div>
</div>

However, if a visible text label is
not possible due to design
limitations, it still needs an
accessible name.

labelledby="a1">
<button aria-label="Close chat window"></button>
</div>
</div>
</div>
</div>

The chat-content container will
contain the dynamically added
messages.

This container can be set with
role="log".

Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Message:
role="log"

labelledby="a1">
<button aria-label="Close chat window"></button>
</div>
<div class="chat-content" role="log">
</div>
</div>
</div>

Elements with role="log" are
classi
fi
ed as live regions and have
an implicit aria-live value of
polite.

This means that each dynamically
added message will be announced
at the next graceful opportunity.

As no aria-atomic value has
been set, it will default to
"false".

This means that assistive
technologies will announce only
newly added messages.
Sandy at 2:15pm. How can I help you?

The "chat-content" container
presents a list of messages. So,
each message could be marked up
as a list item.

<div class="chat-content" role="log">
<ul>
<li class="chat-message-operator">
<span class="chat-details">Sandy at 2:15pm</span>
<span>How can I help you?</span>
</li>
<li class="chat-message-user">
<span class="chat-details">You at 2:17pm</span>
<span>What does it cost?</span>
</li>
</ul>
</div>

The chat-submission container
should contain a <form>.

Hi!
How may I help you?
Sandy at 2:15pm
Sandy at 2:15pm
You at 2:17pm
Message:
form

Users should be able to submit
comments via either the <input>
or <textarea> elements.

The <textarea> element would
allow for multiple lines to be
typed by the user, so it may be a
better option in some cases.

The “Message” text should be
placed inside a <label> element.

<form action="#">
<label>Message</label>
<textarea></textarea>
</form>
</div>

The <label> and <textarea>
elements needs to be
programmatically associated
using matching for and id values.

<form action="#">
<label for="message">Message</label>
<textarea id="message"></textarea>
</form>
</div>

The “Submit” function should be a
<button>.

It should use a visible text label,
but an aria-label could be used
if there are design limitations.

<form action="#">
<button>Submit</button>
</form>
</div>

All of these suggestions could help
to produce a more accessible chat
window.

However, you should always
perform rigorous testing and
include real users as part of the
testing process.

Accessible chat windows

Recommended

Recommended

More Related Content

Similar to Accessible chat windows

Similar to Accessible chat windows (20)

More from Russ Weakley

More from Russ Weakley (20)

Recently uploaded

Recently uploaded (20)

Accessible chat windows