This talk will look at a range of common application components and how they can be made accessible - quickly and easily - for all users. We'll look at how to notify users when changing the DOM after page load. We will also look in-depth at accessible form validation, modal windows and adding additional information for screen reader users.
10. This is where ARIA is used to
provide additional context for
assistive technologies, but the
native elements already have
accessibility APIs available.
18. This is where developers have
copied and pasted components,
often from existing pattern
libraries, without
understanding how the ARIA
attributes work.
19. This can lead to problems such
as aria-labels pointing to non-
existent ID attributes, so the
ARIA does not work.
22. “If you can use a native HTML element
[HTML5] or attribute with the semantics
and behaviour you require already built
in, instead of re-purposing an element and
adding an ARIA role, state or property to
make it accessible, then do so.”
Steve Faulkner:
http://www.paciellogroup.com/blog/2014/10/aria-in-html-there-goes-the-
neighborhood/
24. This should include all major
screen readers in different
browsers. And don’t forget to
test with keyboard only!
25. If possible, work with a range
of real AT users and get their
input/feedback. Make sure your
audience selection includes
different levels of skill.
70. There may be times when you
want to provide different
content for screen readers to
the content that is displayed on-
screen - for links and buttons.
81. More information at “Display
A, announce B - link content”:
http://maxdesign.com.au/jobs/sample-accessibility/06-context/03-different-
content-link.html
85. More information at “Display
A, announce B - button
content”:
http://maxdesign.com.au/jobs/sample-accessibility/06-context/04-different-
content-button.html
92. Adding content after the initial
page has loaded can cause
potential issues for screen
readers.
93. Problem 1:
Screen readers “buffer” pages as
they are loaded. Any content
that is added after this time
many not be picked up by the
screen reader.
94. Problem 2:
Screen readers can only focus on
one part of the page at a time. If
something changes on another
area of the page, screen readers
may not pick this up.
99. If we then use JavaScript to
inject/hide/show content within
this element, screen readers will
be made aware of any DOM
changes within that element.
100. The aria-live attribute can be
used for any page regions that
are likely to get updates after
the initial page is loaded.
101. Success alerts! Your changes are saved
Info alerts! Some info to be aware of
Warning alerts! Something has changed
Error alerts! Fix the error and try again
114. Should only be used if the
interruption is imperative for
users to know immediately
such as error alerts.
115. Unfortunately, aria-
live=“assertive” is not well
supported at this point, so the
“polite” value may be preferred.
http://maxdesign.com.au/jobs/sample-accessibility/10-notifications/
index.html
133. Problem 1:
Form Control Error messages
only appears after a control has
lost focus. For this reason, it is
not immediately presented to
screen reader users.
134. Screen reader users often have
to travel back through the form
to try and find invalid form
controls. If invalid form controls
are not effectively flagged, users
may not be able to find them.
136. In the worst cases, focus
remains on the form submit
button, even after the form has
been found to be invalid, and
screen reader users have no idea
why the form won’t submit.
138. 1. When a form control is
defined as invalid, the control
and associated label should be
“flagged” so that users can be
made aware that there is an
error.
139. 2. Flagging form controls and
associated labels should not use
colour alone to signify errors.
140. 3. An error message should be
displayed in close proximity to
the relevant form control.
153. 4. Each error should ideally be a
link that takes the user to the
relevant form control.
154. The form has two errors that must be completed before it
can be submitted.
1. Error: You must include your first name
2. Error: Email address must include an "@" symbol
155. Optionally, error messages can
be placed inside a hide/show
function that allows users to
choose whether they see the list
of errors or not.
156. The form has two errors that must be completed before it
can be submitted.
View all errors
165. When the error message needs
to be displayed (i.e. the user has
attempted to submit the form
with invalid form controls) some
changes need to occur
dynamically.
166. If present, the tabindex attribute
value needs to be changed from
“-1” to “0” so that the element
will appear in normal tab order.
172. Problem 1:
Keyboard-only users are often
able to TAB outside of the modal
window while the modal is still
active. This can be very
confusing and disconcerting.
221. For some important actions
inside the modal window,
Assistive Technologies should
be given additional
information to let them know
what will happen.
222. As screen reader users are
submitting form data, they
should be informed that:
229. When the modal window is
closed, if users are being taken
back to the parent page:
230. 1. Focus should be placed on
the relevant component of the
parent page. The most common
practice is to move focus back to
the element that invoked the
dialog.
231. The user should not be thrown
back to the top of the parent
page unless there is a good
reason!
232. 2. The user should be informed
where they are and what change
has occurred.
234. Lorem ipsum dolor sit amet consect etuer adipi scing elit sed diam
nonummy nibh euismod tinunt ut laoreet dolore magna aliquam
erat volut. Ut wisi enim ad minim veniam, quis nostrud exerci tation
ullamcorper suscipit lobortis nisl ut aliquip vel eum iriure dolor in
hendrerit in vulputate.
Accumsan et iusto odio dignissim qui blandit praesent luptatum
zzril delenit augue duis dolore te feugait nulla facilisi. Lorem ipsum
dolor sit amet, consectetuer adipiscing elit, sed diam nonummy
nibh euismod tincidunt ut laoreet dolore magna aliquam erat.
Heading here
Another thing here
Add your bank balance
Another heading
$1,200.34
Focus
“Bank balance $1200.34 added
to bank information table”
236. When is the best
time to focus on
accessibility?
237. The best time to focus on
accessibility is right at the
beginning of development
process, when creating the
individual components in your
pattern library.
253. <a class="btn btn-‐default" href="#"
role="button">
Button using a link
</a>
<button class="btn btn-‐default"
type="button">
Button using a button
</button>
254. The problem with this is that it
can lead to some confusion
about when to use a link or a
button.
255. When the incorrect element is
used, this can confuse Assistive
Technology users who expect
links and buttons to behave in
specific ways.