Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Accessible
WEB COMPONENTS
Who the hell 

is this guy?
UX
Accessibility
Front end
Main roles:
Web
Design
Designing &
developing
UI Pattern libraries
for applications
Working with
developers to
build accessible
applications
Pass...
This talk? Some things you can
do to make applications more
accessible.
PART 1
ARIA misuse
Over the last few years there has
been a growing trend to include
ARIA attributes in all sorts of
areas in applications.
Unfortunately, ARIA attributes
can be misused, and this can
lead to all sorts of problems for
AT users.
Problem 1:
Redundancy
This is where ARIA is used to
provide additional context for
assistive technologies, but the
native elements already have
...
<label  for="a"  aria-­‐label="Add  your  email">  
   Add  your  email  
</label>  
<input  type="text"  name="a"  id="a"...
<button  type="submit"  role="button">  
   Submit  
</button>
This can lead to problems such
as form controls being
announced more than once.
Problem 2: 

Overly verbose
This is where ARIA attributes
and additional hidden
information is used extensively
across an application.
This can sometimes lead to
excessive amounts of
information being presented to
AT users.
Problem 3: 

Copy-paste
This is where developers have
copied and pasted components,
often from existing pattern
libraries, without
understanding h...
This can lead to problems such
as aria-labels pointing to non-
existent ID attributes, so the
ARIA does not work.
Solutions?
The simplest guideline is not to
use ARIA unless you really
need to.
“If you can use a native HTML element
[HTML5] or attribute with the semantics
and behaviour you require already built
in, ...
Where possible, test
applications yourself using a
variety of ATs.
This should include all major
screen readers in different
browsers. And don’t forget to
test with keyboard only!
If possible, work with a range
of real AT users and get their
input/feedback. Make sure your
audience selection includes
d...
PART 2
Adding
info for ATs
The problem
There may be times when you
want to provide additional
information to a link or a button
to provide extra context for
scre...
Purchase
This “Purchase” link may be
acceptable for sighted users who
can see the link in context and
do not require additional
inf...
However, screen reader users
may navigate to this link and
hear the word “Purchase”
without any additional
context.
For these users only, we could
provide additional
information to the link:
“Purchase Don Quixote by
Miguel De Cervantes”
Similarly, there may be times
when you want to provide
additional information on a
button.
Close
“Close and return to Account
details”
Solutions for adding
context to links
There are a range of different
methods we could use, such as:
<a  href="#"  title="Purchase  Don  Quixote  by  
Miguel  De  Cervantes">  
   Purchase  
</a>
Win/IE11
Win/IE8
Win/Chrome
Win/Firefox
OSX/Chrome
OSX/Firefox
OSX/Safari
NVDA
FAIL
FAIL
PASS
PASS
-
-
-
JAWS
PASS
PASS
PA...
<a  href="#"  aria-­‐label="Purchase  Don  Quixote  
by  Miguel  De  Cervantes">  
   Purchase  
</a>
Win/IE11
Win/IE8
Win/Chrome
Win/Firefox
OSX/Chrome
OSX/Firefox
OSX/Safari
NVDA
PASS
PASS
FAIL
PASS
-
-
-
JAWS
PASS
PASS
PA...
<a  href="#"  aria-­‐labelledby="info1">  
   Purchase  
</a>  
<p  id="info1"  class="hidden">  
   Don  Quixote  by  Mig...
Win/IE11
Win/IE8
Win/Chrome
Win/Firefox
OSX/Chrome
OSX/Firefox
OSX/Safari
NVDA
PASS
PASS
FAIL
FAIL
-
-
-
JAWS
FAIL
FAIL
FA...
<a  href="#"  aria-­‐describedby="info1">  
   Purchase  
</a>  
<p  id="info1"  class="hidden">  
     Purchase  Don  Qui...
Win/IE11
Win/IE8
Win/Chrome
Win/Firefox
OSX/Chrome
OSX/Firefox
OSX/Safari
NVDA
PASS
PASS
PASS
PASS
-
-
-
JAWS
PASS
PASS
PA...
<a  href="#">  
   Purchase    
   <span  class="hidden">Purchase  Don  Quixote  
by  Miguel  De  Cervantes</span>  
</a>
Win/IE11
Win/IE8
Win/Chrome
Win/Firefox
OSX/Chrome
OSX/Firefox
OSX/Safari
NVDA
PASS
PASS
PASS
PASS
-
-
-
JAWS
PASS
PASS
PA...
The most robust solution
involves using hidden content.
More information at “Adding
information to links”:
http://maxdesign.com.au/jobs/sample-accessibility/06-context/05-adding-...
Solutions for adding
context to buttons
There are a range of different
methods we could use, such as:
<button  title="and  return  to  Account  
details">  
   Close  
</button>
Win/IE11
Win/IE8
Win/Chrome
Win/Firefox
OSX/Chrome
OSX/Firefox
OSX/Safari
NVDA
FAIL
FAIL
PASS
PASS
-
-
-
JAWS
PASS
PASS
PA...
<button  aria-­‐label="Close  and  return  to  
Account  details">  
   Close  
</button>
Win/IE11
Win/IE8
Win/Chrome
Win/Firefox
OSX/Chrome
OSX/Firefox
OSX/Safari
NVDA
PASS
PASS
PASS
PASS
-
-
-
JAWS
PASS
PASS
PA...
<a  href="#"  aria-­‐labelledby="info1">  
   Close  
</a>  
<p  id="info1"  class="hidden">  
   and  return  to  Account...
Win/IE11
Win/IE8
Win/Chrome
Win/Firefox
OSX/Chrome
OSX/Firefox
OSX/Safari
NVDA
PASS
FAIL
FAIL
PASS
-
-
-
JAWS
FAIL
FAIL
FA...
<button  aria-­‐describedby="info1">  
   Close  
</button>  
<p  id="info1"  class="hidden">  
   and  return  to  Accoun...
Win/IE11
Win/IE8
Win/Chrome
Win/Firefox
OSX/Chrome
OSX/Firefox
OSX/Safari
NVDA
PASS
PASS
PASS
PASS
-
-
-
JAWS
FAIL
FAIL
PA...
<button>  
   Close    
   <span  class="hidden">   and  return  to  
Account  details</span>  
</button>
Win/IE11
Win/IE8
Win/Chrome
Win/Firefox
OSX/Chrome
OSX/Firefox
OSX/Safari
NVDA
PASS
PASS
PASS
PASS
-
-
-
JAWS
PASS
PASS
PA...
The most stable choices are
using aria-label or hidden
content.
More information at “Adding
information to buttons”:
http://maxdesign.com.au/jobs/sample-accessibility/06-context/06-addin...
A caution
Providing additional content to
screen readers should be used
with care.
If too much additional
information is provided, it can
make web pages or web
applications too verbose and
hard to use.
PART 3
Different
info for ATs
The problem
There may be times when you
want to provide different
content for screen readers to
the content that is displayed on-
scre...
AED $10,640.00
For example, “AED” may be
acceptable for sighted users but
may not make sense for screen
reader users - especially when
ou...
In certain situation, you may
want to announce different
information to screen reader
users.
“United Arab Emirates Dirham
$10,640.00”
Similarly, there may be times
when you want to provide
different content for screen
readers for buttons.
X
“Close and return to Account
details”
A solution for
different content for
links
<a  href="#">  
   <span  aria-­‐hidden="true">  
      AED  
   </span>    
   <span  class="sr-­‐only">  
      United  ...
Win/IE11
Win/IE8
Win/Chrome
Win/Firefox
OSX/Chrome
OSX/Firefox
OSX/Safari
NVDA
PASS
PASS
PASS
PASS
-
-
-
JAWS
PASS
PASS
PA...
More information at “Display
A, announce B - link content”:
http://maxdesign.com.au/jobs/sample-accessibility/06-context/0...
A solution for
different content for
buttons
<button  type="button"  aria-­‐label="Close  and  
return  to  account  details">  
   x  
</button>
Win/IE11
Win/IE8
Win/Chrome
Win/Firefox
OSX/Chrome
OSX/Firefox
OSX/Safari
NVDA
PASS
PASS
PASS
PASS
-
-
-
JAWS
PASS
PASS
PA...
More information at “Display
A, announce B - button
content”:
http://maxdesign.com.au/jobs/sample-accessibility/06-context...
A caution
Providing different content to
screen readers should be used
with care.
In some situations, providing
different information could
potentially confuse Assistive
Technology users.
PART 4
Dynamic
content
The problem
Well done! Your changes have been saved
Adding content after the initial
page has loaded can cause
potential issues for screen
readers.
Problem 1:
Screen readers “buffer” pages as
they are loaded. Any content
that is added after this time
many not be picked ...
Problem 2:
Screen readers can only focus on
one part of the page at a time. If
something changes on another
area of the pa...
A solution
The aria-live attribute allows us
to notify screen readers when
content is updated in specific
areas of a page.
We can apply the aria-live
attribute to any HTML element.
<div  aria-­‐live="polite">  
</div>
If we then use JavaScript to
inject/hide/show content within
this element, screen readers will
be made aware of any DOM
ch...
The aria-live attribute can be
used for any page regions that
are likely to get updates after
the initial page is loaded.
Success alerts! Your changes are saved
Info alerts! Some info to be aware of
Warning alerts! Something has changed
Error a...
Possible values
There are three possible values
for aria-live: “off”, “polite” and
“assertive”.
<div  aria-­‐live="off">  
</div>
Assistive Technologies should
not announce updates unless
the assistive technology is
currently focused on that region.
Should be used for information
that is not critical for users to
know about immediately.
<div  aria-­‐live="polite">  
</div>
Assistive Technologies should
announce updates at the next
graceful opportunity (e.g. end
of current sentence).
Should be used for warning
notifications that users may
need to know.
<div  aria-­‐live="assertive">  
</div>  
Assistive Technologies should
announce updates
immediately.
Should only be used if the
interruption is imperative for
users to know immediately
such as error alerts.
Unfortunately, aria-
live=“assertive” is not well
supported at this point, so the
“polite” value may be preferred.
http://...
aria-relevant
aria-relevant
This attribute gives a hint about
what types of changes are
relevant and should be
announced by Assistive
Te...
<!-­‐-­‐  Insertion  of  nodes  into  the  live  region  
should  be  considered  relevant  -­‐-­‐>  
<div  aria-­‐relevan...
<!-­‐-­‐  Deletion  of  nodes  should  be  considered  
relevant  
  -­‐-­‐>  
<div  aria-­‐relevant="removals">  
</div>  
<!-­‐-­‐  Changes  to  the  textual  content  of  
existing  nodes  should  be  considered  relevant  
-­‐-­‐>  
<div  ari...
<!-­‐-­‐  All  changed  nodes  should  be  considered  
relevant  -­‐-­‐>  
<div  aria-­‐relevant="all">  
</div>  
The default behaviour is
equivalent to “additions text”.
aria-relevant values of
“removals” or “all” should be
used sparingly.
role=alert
role=“alert”
Defines a message with
important information.
<div  role="alert">  
</div>  
Elements with the role=“alert”
have an implicit aria-live value
of “assertive”.
PART 5
Error messages
We’re going to look at two
different aspects of client-side
form validation.
1. Form control validation
Individual form fields are
validated as the user moves
focus out of the form control.
2. On-submit form validation
The entire form is validated as
the user submits the form -
before the script sends the form
...
The problem
Problem 1:
Form Control Error messages
only appears after a control has
lost focus. For this reason, it is
not immediately...
Screen reader users often have
to travel back through the form
to try and find invalid form
controls. If invalid form cont...
Problem 2:
Screen reader users are often
not informed that the overall
form contains errors.
In the worst cases, focus
remains on the form submit
button, even after the form has
been found to be invalid, and
screen ...
A solution for 

form control validation
1. When a form control is
defined as invalid, the control
and associated label should be
“flagged” so that users can be
ma...
2. Flagging form controls and
associated labels should not use
colour alone to signify errors.
3. An error message should be
displayed in close proximity to
the relevant form control.
Error: The phone number must include a 10 digit number
Phone
4. The error message should be
informative - it should provide
information that will help users
fill in the field correctl...
5. The error message should be
programmatically associated
with the form control.
This means that the error
message should be announced
along with the relevant label
information.
There are a range of different
methods to programmatically
associate error messages with
form controls.
The simplest is to place the
error message content inside
the label.
<div>  
   <label  for="email">  
      Email  
      <input  type="email"  id="email">  
      <span  class="error">Error...
A solution
for on-submit
form validation
If there are one or more form
validation errors:
1. An error message should
appear at the top of the form
alerting users that there are
errors.
2. Focus must be taken to the
error message as soon as the
user has attempted to submit for
form.
3. The error message should list
all errors.
4. Each error should ideally be a
link that takes the user to the
relevant form control.
The form has two errors that must be completed before it 

can be submitted.

1. Error: You must include your first name

2...
Optionally, error messages can
be placed inside a hide/show
function that allows users to
choose whether they see the list...
The form has two errors that must be completed before it 

can be submitted.

View all errors
Markup for error
messages
The error message container can
exist on the page, even when
non-active. However, it should
not contain any content until
...
This container should be set
with role=“alert”. This is used
to communicate important
information.
<div    
   class="error-­‐message-­‐container"    
   role="alert">  
</div>
Optionally, the aria-live
attribute can added with a value
of “assertive” or “polite”.
<div    
   class="error-­‐message-­‐container"    
   role="alert"  
   aria-­‐live="polite">  
</div>
This container can be set with
tabindex value of “-1” so that it
will not receive focus.
<div    
   class="error-­‐message-­‐container"    
   role="alert"  
   aria-­‐live="polite"  
   tabindex="-­‐1">  
</di...
When the error message needs
to be displayed (i.e. the user has
attempted to submit the form
with invalid form controls) s...
If present, the tabindex attribute
value needs to be changed from
“-1” to “0” so that the element
will appear in normal ta...
<div  
   class="error-­‐message-­‐container"  
   role="alert"  
   aria-­‐live="polite"  
   tabindex="0">  
</div>  
The container can be given a
label so that it is announced to
screen reader users.
<div  
   class="error-­‐message-­‐container"  
   role="alert"  
   aria-­‐live="polite"  
   tabindex="0"  
   aria-­‐la...
PART 6
Modals
The problem
Problem 1:
Keyboard-only users are often
able to TAB outside of the modal
window while the modal is still
active. This can...
Problem 2:
Screen reader users are
sometimes not informed that an
action will trigger a modal.
Problem 3:
Screen reader users are
sometimes not made aware of
the purpose of the modal or
what actions they need to
perfo...
Problem 4:
Screen reader users are
sometimes sent to the top of the
parent page after a modal
window has been closed. This...
A solution
When a modal is not in use, we
need to hide it so that is not
seen by sighted users or
announced to Screen Readers.
<div  
   style="display:none">  
   ...  
</div>  
When a modal window is
triggered, we need to change
the value.
<div  
   style="display:block">  
   ...  
</div>  
When the modal window
becomes active, all other
content should be hidden from
Assistive Technologies.
<!-­‐-­‐  all  other  content  -­‐-­‐>  
<div  
   aria-­‐hidden="true">  
   ...  
</div>  
<!-­‐-­‐  modal  window  -­‐-...
We need to set the initial focus
to the modal window element
itself rather than elements inside
the modal.
Initial focus
Initial focus
This is important because we are
going to give the modal a
label.
If we set focus on an element
inside the window, the label
will not be announced to
Assistive Technologies.
We need to inform screen reader
users that this modal window is
a “modal dialog”.
<div  
   style="display:block"  
   role="dialog">  
   ...  
</div>
We need to provide a label for
the modal dialog, so Assistive
Technologies can announce its
purpose.
<div  
   style="display:block"  
   role="dialog"  
   aria-­‐labelledby="modal-­‐label">  
   <h1  id="modal-­‐label">Ch...
In some circumstances, we may
need to provide a more
detailed description of the
purpose of the modal dialog.
<div  
   style="display:block"  
   role="dialog"  
   aria-­‐labelledby="modal-­‐label"  
   aria-­‐describedby="modal-­...
Keystrokes
TAB
TAB
TAB
TAB
TAB
TAB
TAB
TAB
SHIFT + TAB
SHIFT + TAB
SHIFT + TAB
SHIFT + TAB
SHIFT + TAB
SHIFT + TAB
SHIFT + TAB
ENTER
ENTER
SPACE
SPACE
TAB
ARROW
Option 1 - apples
ARROW
Option 2 - pears
ARROW
Option 3 - bananas
ARROW
ESC
Adding meaning to
important actions
For some important actions
inside the modal window,
Assistive Technologies should
be given additional
information to let t...
As screen reader users are
submitting form data, they
should be informed that:
1. They will be taken back to
the parent page.
2. Where this data will be
submitted when they return to
the parent page.
ENTER
“Submit and return to bank
balance information. Your
data will be added to the
Balance table”
As screen reader users focus on
the “Close” function, they
should be informed that
closing will take them back to
the pare...
ENTER
“Leave form and return to
bank balance information”
After modal dialog
closes
When the modal window is
closed, if users are being taken
back to the parent page:
1. Focus should be placed on
the relevant component of the
parent page. The most common
practice is to move focus back to
...
The user should not be thrown
back to the top of the parent
page unless there is a good
reason!
2. The user should be informed
where they are and what change
has occurred.
ENTER
Lorem ipsum dolor sit amet consect etuer adipi scing elit sed diam
nonummy nibh euismod tinunt ut laoreet dolore magna ali...
PART 7
Where to start?
When is the best
time to focus on
accessibility?
The best time to focus on
accessibility is right at the
beginning of development
process, when creating the
individual com...
Quick steps you can
do yourself
Don’t be overwhelmed. Look
for quick wins. You’ll be
surprised what you can do
without too much effort.
Test with keyboard-only
and make changes as
needed. (Make sure you
also check for visible
focus).
1
/*  avoid  this!  */  
:focus  {  outline:  none;  }
Test with accessibility
checking tools and make
changes as needed.2
Tenon
https://tenon.io/
Web Accessibility Toolbar
https://www.paciellogroup.com/resources/wat/
Accessibility Viewer
https:...
Accessibility Evaluation Toolbar 1.5.7.1.1
https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation-
toolb/...
Test with one or more
screen readers and make
changes as needed.3
Win/IE11
Win/IE8
Win/Chrome
Win/Firefox
OSX/Chrome
OSX/Firefox
OSX/Safari
NVDA
PASS/FAIL
PASS/FAIL
PASS/FAIL
PASS/FAIL
-
-...
Get expert assistance and
conduct a formal
accessibility audit of your
website or web application
and action as needed.
4
Russ Weakley
Max Design

Site: maxdesign.com.au

Twitter: twitter.com/russmaxdesign

Slideshare: slideshare.net/maxdesign
...
PART 1
Buttons vs
links
https://www.flickr.com/photos/edanley/3246241416
The problem
Some developers use CSS button
classes that allow them to make
any element appear like a
button, even if it is a link.
This is a link
This is a button
<a  class="btn  btn-­‐default"  href="#"  
role="button">  
   Button  using  a  link  
</a>  
<button  class="btn  btn-­‐...
The problem with this is that it
can lead to some confusion
about when to use a link or a
button.
When the incorrect element is
used, this can confuse Assistive
Technology users who expect
links and buttons to behave in
...
The solution
Use a link when you want to
send the user to a new
location - like a different page.
Use a button when you want the
user to perform some sort of
action - like click a button,
submit a form, open an
accordion.
Building Accessible Web Components
Building Accessible Web Components
Upcoming SlideShare
Loading in …5
×

Building Accessible Web Components

1,228 views

Published on

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.

Published in: Education
  • Be the first to comment

Building Accessible Web Components

  1. 1. Accessible WEB COMPONENTS
  2. 2. Who the hell 
 is this guy?
  3. 3. UX Accessibility Front end Main roles: Web Design
  4. 4. Designing & developing UI Pattern libraries for applications Working with developers to build accessible applications Passions:
  5. 5. This talk? Some things you can do to make applications more accessible.
  6. 6. PART 1 ARIA misuse
  7. 7. Over the last few years there has been a growing trend to include ARIA attributes in all sorts of areas in applications.
  8. 8. Unfortunately, ARIA attributes can be misused, and this can lead to all sorts of problems for AT users.
  9. 9. Problem 1: Redundancy
  10. 10. This is where ARIA is used to provide additional context for assistive technologies, but the native elements already have accessibility APIs available.
  11. 11. <label  for="a"  aria-­‐label="Add  your  email">     Add  your  email   </label>   <input  type="text"  name="a"  id="a">  
  12. 12. <button  type="submit"  role="button">     Submit   </button>
  13. 13. This can lead to problems such as form controls being announced more than once.
  14. 14. Problem 2: 
 Overly verbose
  15. 15. This is where ARIA attributes and additional hidden information is used extensively across an application.
  16. 16. This can sometimes lead to excessive amounts of information being presented to AT users.
  17. 17. Problem 3: 
 Copy-paste
  18. 18. This is where developers have copied and pasted components, often from existing pattern libraries, without understanding how the ARIA attributes work.
  19. 19. This can lead to problems such as aria-labels pointing to non- existent ID attributes, so the ARIA does not work.
  20. 20. Solutions?
  21. 21. The simplest guideline is not to use ARIA unless you really need to.
  22. 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/
  23. 23. Where possible, test applications yourself using a variety of ATs.
  24. 24. This should include all major screen readers in different browsers. And don’t forget to test with keyboard only!
  25. 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.
  26. 26. PART 2 Adding info for ATs
  27. 27. The problem
  28. 28. There may be times when you want to provide additional information to a link or a button to provide extra context for screen reader users.
  29. 29. Purchase
  30. 30. This “Purchase” link may be acceptable for sighted users who can see the link in context and do not require additional information.
  31. 31. However, screen reader users may navigate to this link and hear the word “Purchase” without any additional context.
  32. 32. For these users only, we could provide additional information to the link:
  33. 33. “Purchase Don Quixote by Miguel De Cervantes”
  34. 34. Similarly, there may be times when you want to provide additional information on a button.
  35. 35. Close
  36. 36. “Close and return to Account details”
  37. 37. Solutions for adding context to links
  38. 38. There are a range of different methods we could use, such as:
  39. 39. <a  href="#"  title="Purchase  Don  Quixote  by   Miguel  De  Cervantes">     Purchase   </a>
  40. 40. Win/IE11 Win/IE8 Win/Chrome Win/Firefox OSX/Chrome OSX/Firefox OSX/Safari NVDA FAIL FAIL PASS PASS - - - JAWS PASS PASS PASS PASS - - - Voiceover - - - - FAIL FAIL PASS
  41. 41. <a  href="#"  aria-­‐label="Purchase  Don  Quixote   by  Miguel  De  Cervantes">     Purchase   </a>
  42. 42. Win/IE11 Win/IE8 Win/Chrome Win/Firefox OSX/Chrome OSX/Firefox OSX/Safari NVDA PASS PASS FAIL PASS - - - JAWS PASS PASS PASS PASS - - - Voiceover - - - - PASS PASS PASS
  43. 43. <a  href="#"  aria-­‐labelledby="info1">     Purchase   </a>   <p  id="info1"  class="hidden">     Don  Quixote  by  Miguel  De  Cervantes   </p>
  44. 44. Win/IE11 Win/IE8 Win/Chrome Win/Firefox OSX/Chrome OSX/Firefox OSX/Safari NVDA PASS PASS FAIL FAIL - - - JAWS FAIL FAIL FAIL FAIL - - - Voiceover - - - - PASS PASS PASS
  45. 45. <a  href="#"  aria-­‐describedby="info1">     Purchase   </a>   <p  id="info1"  class="hidden">      Purchase  Don  Quixote  by  Miguel  De   Cervantes   </p>
  46. 46. Win/IE11 Win/IE8 Win/Chrome Win/Firefox OSX/Chrome OSX/Firefox OSX/Safari NVDA PASS PASS PASS PASS - - - JAWS PASS PASS PASS PASS - - - Voiceover - - - - FAIL PASS PASS
  47. 47. <a  href="#">     Purchase       <span  class="hidden">Purchase  Don  Quixote   by  Miguel  De  Cervantes</span>   </a>
  48. 48. Win/IE11 Win/IE8 Win/Chrome Win/Firefox OSX/Chrome OSX/Firefox OSX/Safari NVDA PASS PASS PASS PASS - - - JAWS PASS PASS PASS PASS - - - Voiceover - - - - PASS PASS PASS
  49. 49. The most robust solution involves using hidden content.
  50. 50. More information at “Adding information to links”: http://maxdesign.com.au/jobs/sample-accessibility/06-context/05-adding- to-links.html
  51. 51. Solutions for adding context to buttons
  52. 52. There are a range of different methods we could use, such as:
  53. 53. <button  title="and  return  to  Account   details">     Close   </button>
  54. 54. Win/IE11 Win/IE8 Win/Chrome Win/Firefox OSX/Chrome OSX/Firefox OSX/Safari NVDA FAIL FAIL PASS PASS - - - JAWS PASS PASS PASS PASS - - - Voiceover - - - - FAIL FAIL FAIL
  55. 55. <button  aria-­‐label="Close  and  return  to   Account  details">     Close   </button>
  56. 56. Win/IE11 Win/IE8 Win/Chrome Win/Firefox OSX/Chrome OSX/Firefox OSX/Safari NVDA PASS PASS PASS PASS - - - JAWS PASS PASS PASS PASS - - - Voiceover - - - - PASS PASS PASS
  57. 57. <a  href="#"  aria-­‐labelledby="info1">     Close   </a>   <p  id="info1"  class="hidden">     and  return  to  Account  details   </p>
  58. 58. Win/IE11 Win/IE8 Win/Chrome Win/Firefox OSX/Chrome OSX/Firefox OSX/Safari NVDA PASS FAIL FAIL PASS - - - JAWS FAIL FAIL FAIL FAIL - - - Voiceover - - - - FAIL FAIL FAIL
  59. 59. <button  aria-­‐describedby="info1">     Close   </button>   <p  id="info1"  class="hidden">     and  return  to  Account  details   </p>
  60. 60. Win/IE11 Win/IE8 Win/Chrome Win/Firefox OSX/Chrome OSX/Firefox OSX/Safari NVDA PASS PASS PASS PASS - - - JAWS FAIL FAIL PASS PASS - - - Voiceover - - - - FAIL FAIL FAIL
  61. 61. <button>     Close       <span  class="hidden">   and  return  to   Account  details</span>   </button>
  62. 62. Win/IE11 Win/IE8 Win/Chrome Win/Firefox OSX/Chrome OSX/Firefox OSX/Safari NVDA PASS PASS PASS PASS - - - JAWS PASS PASS PASS PASS - - - Voiceover - - - - PASS PASS PASS
  63. 63. The most stable choices are using aria-label or hidden content.
  64. 64. More information at “Adding information to buttons”: http://maxdesign.com.au/jobs/sample-accessibility/06-context/06-adding- to-buttons.html
  65. 65. A caution
  66. 66. Providing additional content to screen readers should be used with care.
  67. 67. If too much additional information is provided, it can make web pages or web applications too verbose and hard to use.
  68. 68. PART 3 Different info for ATs
  69. 69. The problem
  70. 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.
  71. 71. AED $10,640.00
  72. 72. For example, “AED” may be acceptable for sighted users but may not make sense for screen reader users - especially when out of context.
  73. 73. In certain situation, you may want to announce different information to screen reader users.
  74. 74. “United Arab Emirates Dirham $10,640.00”
  75. 75. Similarly, there may be times when you want to provide different content for screen readers for buttons.
  76. 76. X
  77. 77. “Close and return to Account details”
  78. 78. A solution for different content for links
  79. 79. <a  href="#">     <span  aria-­‐hidden="true">       AED     </span>       <span  class="sr-­‐only">       United  Arab  Emirates  Dirham     </span>   </a>
  80. 80. Win/IE11 Win/IE8 Win/Chrome Win/Firefox OSX/Chrome OSX/Firefox OSX/Safari NVDA PASS PASS PASS PASS - - - JAWS PASS PASS PASS PASS - - - Voiceover - - - - PASS PASS PASS
  81. 81. More information at “Display A, announce B - link content”: http://maxdesign.com.au/jobs/sample-accessibility/06-context/03-different- content-link.html
  82. 82. A solution for different content for buttons
  83. 83. <button  type="button"  aria-­‐label="Close  and   return  to  account  details">     x   </button>
  84. 84. Win/IE11 Win/IE8 Win/Chrome Win/Firefox OSX/Chrome OSX/Firefox OSX/Safari NVDA PASS PASS PASS PASS - - - JAWS PASS PASS PASS PASS - - - Voiceover - - - - PASS PASS PASS
  85. 85. More information at “Display A, announce B - button content”: http://maxdesign.com.au/jobs/sample-accessibility/06-context/04-different- content-button.html
  86. 86. A caution
  87. 87. Providing different content to screen readers should be used with care.
  88. 88. In some situations, providing different information could potentially confuse Assistive Technology users.
  89. 89. PART 4 Dynamic content
  90. 90. The problem
  91. 91. Well done! Your changes have been saved
  92. 92. Adding content after the initial page has loaded can cause potential issues for screen readers.
  93. 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. 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.
  95. 95. A solution
  96. 96. The aria-live attribute allows us to notify screen readers when content is updated in specific areas of a page.
  97. 97. We can apply the aria-live attribute to any HTML element.
  98. 98. <div  aria-­‐live="polite">   </div>
  99. 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. 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. 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
  102. 102. Possible values
  103. 103. There are three possible values for aria-live: “off”, “polite” and “assertive”.
  104. 104. <div  aria-­‐live="off">   </div>
  105. 105. Assistive Technologies should not announce updates unless the assistive technology is currently focused on that region.
  106. 106. Should be used for information that is not critical for users to know about immediately.
  107. 107. <div  aria-­‐live="polite">   </div>
  108. 108. Assistive Technologies should announce updates at the next graceful opportunity (e.g. end of current sentence).
  109. 109. Should be used for warning notifications that users may need to know.
  110. 110. <div  aria-­‐live="assertive">   </div>  
  111. 111. Assistive Technologies should announce updates immediately.
  112. 112. Should only be used if the interruption is imperative for users to know immediately such as error alerts.
  113. 113. 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
  114. 114. aria-relevant
  115. 115. aria-relevant This attribute gives a hint about what types of changes are relevant and should be announced by Assistive Technologies.
  116. 116. <!-­‐-­‐  Insertion  of  nodes  into  the  live  region   should  be  considered  relevant  -­‐-­‐>   <div  aria-­‐relevant="additions">   </div>  
  117. 117. <!-­‐-­‐  Deletion  of  nodes  should  be  considered   relevant    -­‐-­‐>   <div  aria-­‐relevant="removals">   </div>  
  118. 118. <!-­‐-­‐  Changes  to  the  textual  content  of   existing  nodes  should  be  considered  relevant   -­‐-­‐>   <div  aria-­‐relevant="text">   </div>  
  119. 119. <!-­‐-­‐  All  changed  nodes  should  be  considered   relevant  -­‐-­‐>   <div  aria-­‐relevant="all">   </div>  
  120. 120. The default behaviour is equivalent to “additions text”.
  121. 121. aria-relevant values of “removals” or “all” should be used sparingly.
  122. 122. role=alert
  123. 123. role=“alert” Defines a message with important information.
  124. 124. <div  role="alert">   </div>  
  125. 125. Elements with the role=“alert” have an implicit aria-live value of “assertive”.
  126. 126. PART 5 Error messages
  127. 127. We’re going to look at two different aspects of client-side form validation.
  128. 128. 1. Form control validation Individual form fields are validated as the user moves focus out of the form control.
  129. 129. 2. On-submit form validation The entire form is validated as the user submits the form - before the script sends the form to the server.
  130. 130. The problem
  131. 131. 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.
  132. 132. 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.
  133. 133. Problem 2: Screen reader users are often not informed that the overall form contains errors.
  134. 134. 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.
  135. 135. A solution for 
 form control validation
  136. 136. 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.
  137. 137. 2. Flagging form controls and associated labels should not use colour alone to signify errors.
  138. 138. 3. An error message should be displayed in close proximity to the relevant form control.
  139. 139. Error: The phone number must include a 10 digit number Phone
  140. 140. 4. The error message should be informative - it should provide information that will help users fill in the field correctly.
  141. 141. 5. The error message should be programmatically associated with the form control.
  142. 142. This means that the error message should be announced along with the relevant label information.
  143. 143. There are a range of different methods to programmatically associate error messages with form controls.
  144. 144. The simplest is to place the error message content inside the label.
  145. 145. <div>     <label  for="email">       Email       <input  type="email"  id="email">       <span  class="error">Error</span>     </label>   </div>  
  146. 146. A solution for on-submit form validation
  147. 147. If there are one or more form validation errors:
  148. 148. 1. An error message should appear at the top of the form alerting users that there are errors.
  149. 149. 2. Focus must be taken to the error message as soon as the user has attempted to submit for form.
  150. 150. 3. The error message should list all errors.
  151. 151. 4. Each error should ideally be a link that takes the user to the relevant form control.
  152. 152. 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
  153. 153. 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.
  154. 154. The form has two errors that must be completed before it can be submitted. View all errors
  155. 155. Markup for error messages
  156. 156. The error message container can exist on the page, even when non-active. However, it should not contain any content until triggered.
  157. 157. This container should be set with role=“alert”. This is used to communicate important information.
  158. 158. <div       class="error-­‐message-­‐container"       role="alert">   </div>
  159. 159. Optionally, the aria-live attribute can added with a value of “assertive” or “polite”.
  160. 160. <div       class="error-­‐message-­‐container"       role="alert"     aria-­‐live="polite">   </div>
  161. 161. This container can be set with tabindex value of “-1” so that it will not receive focus.
  162. 162. <div       class="error-­‐message-­‐container"       role="alert"     aria-­‐live="polite"     tabindex="-­‐1">   </div>
  163. 163. 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.
  164. 164. If present, the tabindex attribute value needs to be changed from “-1” to “0” so that the element will appear in normal tab order.
  165. 165. <div     class="error-­‐message-­‐container"     role="alert"     aria-­‐live="polite"     tabindex="0">   </div>  
  166. 166. The container can be given a label so that it is announced to screen reader users.
  167. 167. <div     class="error-­‐message-­‐container"     role="alert"     aria-­‐live="polite"     tabindex="0"     aria-­‐label="Form  Errors">   </div>  
  168. 168. PART 6 Modals
  169. 169. The problem
  170. 170. 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.
  171. 171. Problem 2: Screen reader users are sometimes not informed that an action will trigger a modal.
  172. 172. Problem 3: Screen reader users are sometimes not made aware of the purpose of the modal or what actions they need to perform within the modal.
  173. 173. Problem 4: Screen reader users are sometimes sent to the top of the parent page after a modal window has been closed. This can be confusing.
  174. 174. A solution
  175. 175. When a modal is not in use, we need to hide it so that is not seen by sighted users or announced to Screen Readers.
  176. 176. <div     style="display:none">     ...   </div>  
  177. 177. When a modal window is triggered, we need to change the value.
  178. 178. <div     style="display:block">     ...   </div>  
  179. 179. When the modal window becomes active, all other content should be hidden from Assistive Technologies.
  180. 180. <!-­‐-­‐  all  other  content  -­‐-­‐>   <div     aria-­‐hidden="true">     ...   </div>   <!-­‐-­‐  modal  window  -­‐-­‐>   <div     style="display:block">     ...   </div>  
  181. 181. We need to set the initial focus to the modal window element itself rather than elements inside the modal.
  182. 182. Initial focus
  183. 183. Initial focus
  184. 184. This is important because we are going to give the modal a label.
  185. 185. If we set focus on an element inside the window, the label will not be announced to Assistive Technologies.
  186. 186. We need to inform screen reader users that this modal window is a “modal dialog”.
  187. 187. <div     style="display:block"     role="dialog">     ...   </div>
  188. 188. We need to provide a label for the modal dialog, so Assistive Technologies can announce its purpose.
  189. 189. <div     style="display:block"     role="dialog"     aria-­‐labelledby="modal-­‐label">     <h1  id="modal-­‐label">Choose  account</h1>   </div>  
  190. 190. In some circumstances, we may need to provide a more detailed description of the purpose of the modal dialog.
  191. 191. <div     style="display:block"     role="dialog"     aria-­‐labelledby="modal-­‐label"     aria-­‐describedby="modal-­‐description">     <h1  id="modal-­‐label">Choose  account</h1>     <p  id="modal-­‐description">       Description  here     </p>   </div>  
  192. 192. Keystrokes
  193. 193. TAB
  194. 194. TAB
  195. 195. TAB
  196. 196. TAB
  197. 197. TAB
  198. 198. TAB
  199. 199. TAB
  200. 200. TAB
  201. 201. SHIFT + TAB
  202. 202. SHIFT + TAB
  203. 203. SHIFT + TAB
  204. 204. SHIFT + TAB
  205. 205. SHIFT + TAB
  206. 206. SHIFT + TAB
  207. 207. SHIFT + TAB
  208. 208. ENTER
  209. 209. ENTER
  210. 210. SPACE
  211. 211. SPACE
  212. 212. TAB
  213. 213. ARROW
  214. 214. Option 1 - apples ARROW
  215. 215. Option 2 - pears ARROW
  216. 216. Option 3 - bananas ARROW
  217. 217. ESC
  218. 218. Adding meaning to important actions
  219. 219. For some important actions inside the modal window, Assistive Technologies should be given additional information to let them know what will happen.
  220. 220. As screen reader users are submitting form data, they should be informed that:
  221. 221. 1. They will be taken back to the parent page.
  222. 222. 2. Where this data will be submitted when they return to the parent page.
  223. 223. ENTER “Submit and return to bank balance information. Your data will be added to the Balance table”
  224. 224. As screen reader users focus on the “Close” function, they should be informed that closing will take them back to the parent page.
  225. 225. ENTER “Leave form and return to bank balance information”
  226. 226. After modal dialog closes
  227. 227. When the modal window is closed, if users are being taken back to the parent page:
  228. 228. 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.
  229. 229. The user should not be thrown back to the top of the parent page unless there is a good reason!
  230. 230. 2. The user should be informed where they are and what change has occurred.
  231. 231. ENTER
  232. 232. 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”
  233. 233. PART 7 Where to start?
  234. 234. When is the best time to focus on accessibility?
  235. 235. The best time to focus on accessibility is right at the beginning of development process, when creating the individual components in your pattern library.
  236. 236. Quick steps you can do yourself
  237. 237. Don’t be overwhelmed. Look for quick wins. You’ll be surprised what you can do without too much effort.
  238. 238. Test with keyboard-only and make changes as needed. (Make sure you also check for visible focus). 1
  239. 239. /*  avoid  this!  */   :focus  {  outline:  none;  }
  240. 240. Test with accessibility checking tools and make changes as needed.2
  241. 241. Tenon https://tenon.io/ Web Accessibility Toolbar https://www.paciellogroup.com/resources/wat/ Accessibility Viewer https://www.paciellogroup.com/resources/aviewer Colour Contrast Analyser https://www.paciellogroup.com/resources/contrastanalyser/
  242. 242. Accessibility Evaluation Toolbar 1.5.7.1.1 https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation- toolb/ WAVE http://wave.webaim.org/ Total Validator http://www.totalvalidator.com/ CynthisSays http://www.cynthiasays.com/
  243. 243. Test with one or more screen readers and make changes as needed.3
  244. 244. Win/IE11 Win/IE8 Win/Chrome Win/Firefox OSX/Chrome OSX/Firefox OSX/Safari NVDA PASS/FAIL PASS/FAIL PASS/FAIL PASS/FAIL - - - JAWS PASS/FAIL PASS/FAIL PASS/FAIL PASS/FAIL - - - Voiceover - - - - PASS/FAIL PASS/FAIL PASS/FAIL
  245. 245. Get expert assistance and conduct a formal accessibility audit of your website or web application and action as needed. 4
  246. 246. Russ Weakley Max Design Site: maxdesign.com.au Twitter: twitter.com/russmaxdesign Slideshare: slideshare.net/maxdesign Linkedin: linkedin.com/in/russweakley
  247. 247. PART 1 Buttons vs links https://www.flickr.com/photos/edanley/3246241416
  248. 248. The problem
  249. 249. Some developers use CSS button classes that allow them to make any element appear like a button, even if it is a link.
  250. 250. This is a link This is a button
  251. 251. <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>
  252. 252. The problem with this is that it can lead to some confusion about when to use a link or a button.
  253. 253. When the incorrect element is used, this can confuse Assistive Technology users who expect links and buttons to behave in specific ways.
  254. 254. The solution
  255. 255. Use a link when you want to send the user to a new location - like a different page.
  256. 256. Use a button when you want the user to perform some sort of action - like click a button, submit a form, open an accordion.

×