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.
without tears
Building accessible web components
Four painful questions
Have you ever tried to navigate
through your web site or
application using the
keyboard only (no mouse)?
1
Were you able to perform all
the site/application tasks
without issues?
2
As you navigated through the
application using keyboard
only, could you always see
the element that was in
focus?
3
Was tab order in a logical
order (that reflected the on-
screen order) or did focus jump
all around the page?
4
The myth of
“Full stack”
Over the last 5 years, 

there seems to have been 

a major change in front end
development.
Developers are now being
asked to be fluent in all sorts
of libraries and frameworks -
to be “full stack” developers.
But many “full stack”
developers seem to have
forgotten some of the core
web principles…
Like… understanding basic
HTML, CSS, accessibility, and
using progressive
enhancement.
“Why can’t I
wrap a span
around a div?”
Web accessibility
begins with
semantic markup
https://www.flickr.com/photos/tinto/16027598548
Why should I care?
One of our core roles as web
professionals is making sure
our sites /applications can be
used by the widest possible
audie...
This means everyone,
including people with
disabilities that include: Visual,
Auditory, Motor skill and
Cognitive
This also means making our
sites and apps accessible for
Assistive Technologies:
Input devices: 

Accessible keyboards, Track
pads, Head wands, Puffers,
Switches, Touch screens, Voice
activation software,...
Output devices: 

Text-based browsers, Screen
Readers, Magnifiers,
Refreshable Braille Devices
etc.
Assistive
Technologies are
more than just
screen readers
Don’t panic!
All of this may sound time
consuming and costly, but it
doesn’t have to be.
I'm going to talk about some
quick things you can do to
make some common
application components more
accessible.
I’ll be focussing on some
components that often
present major barriers to
Assistive Technologies.
Online tests
I have a range of online tests
available, which show how
different assistive technologies
work with application
components....
WAI ARIA
WAI: Web Accessibility
Initiative
ARIA: Accessible Rich Internet
Applications
WAI-ARIA defines a way to
make web sites and web
applications more accessible -
especially advanced
JavaScript-based
compon...
We can use HTML attributes to
define the role, states and
properties of specific HTML
elements.
Roles:
Is it a widget (menu, slider,
progress bar etc.) or an
important type of element
(heading, region, table, form
etc.)
<ul  role="menu">  
   ...  
</ul>  
<main  role="main">  
   ...  
</main>
States:
What is the current state of the
widget? Is it checked, disabled
etc.
<input  aria-­‐disabled="true"  type="text">  
<input  aria-­‐checked="true"  type="radio">
Properties:
What are the properties of the
widget? Does it have live
regions, does it have
relationships with other
elemen...
<button  aria-­‐label="Close  and  return  to  
application">  
   Close  
</button>  
<a  href="#"  aria-­‐describedby="i...
ARIA allows us to
make specific HTML
elements more
meaningful for ATs
Dynamic content
The problem
Well done! Your changes have been saved
Inserted after page load
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 u...
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...
Dynamic stock info
Sortable tables
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”.
aria-live:
easy to apply,
major benefits
Accessible Errors
https://www.pexels.com/photo/animal-dog-pet-sad-7289/
Screen reader
modes
It is important to understand
that Screen Reader users
generally read and interact
with web pages in two main
ways:
‘Read’ mode:
Users can read and navigate
the page but can not enter
data into form controls.
‘Form’ mode:
User can enter data into form
controls. Keyboard access is
restricted to page elements
that can accept focus.
These days, screen readers
will automatically switch
between these two modes -
though users can manually
trigger these mod...
Why do these
two modes
matter?
If a screen reader is in forms
mode, content that is not
directly associated with form
controls may not be
announced.
<!-­‐-­‐  this  error  message  may  not  be  announced  
-­‐-­‐>  
<div>  
   <label  for="email">Email</label>  
   <inp...
Types of form
validation
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
contr...
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
made...
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
correctly.
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...
Accessible form
errors:
simple solutions,
major benefits.
Accessible 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...
Modals are a pain,
but we can make
them less painful
Accessible tabs
https://www.flickr.com/photos/quandc/16426960180
The problem
In-page tabs can present
issues for screen reader as
well as keyboard-only users.
Problem 1:
Screen reader users are often
confused by the relationship
between tabs and panels.
Problem 2:
Keyboard-only users are often
unable to navigate through the
tabs and panels simply or
intuitively.
A solution
The preferred keyboard-only
navigation method for in-
page tabs uses TAB keystrokes
to move onto the active tab
and active...
“TAB & ARROW”:
Straight through
pass
Tab 1 Tab 2 Tab 3
This is a heading inside Tab 1
Lorem ipsum dolor sit amet consect etuer adipi
scing elit sed diam nonumm...
Tab 1 Tab 2 Tab 3
This is a heading inside Tab 1
Lorem ipsum dolor sit amet consect etuer adipi
scing elit sed diam nonumm...
Tab 1 Tab 2 Tab 3
This is a heading inside Tab 1
Lorem ipsum dolor sit amet consect etuer adipi
scing elit sed diam nonumm...
Tab 1 Tab 2 Tab 3
This is a heading inside Tab 1
Lorem ipsum dolor sit amet consect etuer adipi
scing elit sed diam nonumm...
Tab 1 Tab 2 Tab 3
This is a heading inside Tab 1
Lorem ipsum dolor sit amet consect etuer adipi
scing elit sed diam nonumm...
“TAB & ARROW”:
Across the tabs
pass
Tab 1 Tab 2 Tab 3
This is a heading inside Tab 1
Lorem ipsum dolor sit amet consect etuer adipi
scing elit sed diam nonumm...
Tab 1 Tab 2 Tab 3
This is a heading inside Tab 2
Lorem ipsum dolor sit amet consect etuer adipi
scing elit sed diam nonumm...
Tab 1 Tab 2 Tab 3
This is a heading inside Tab 3
Lorem ipsum dolor sit amet consect etuer adipi
scing elit sed diam nonumm...
Tab 1 Tab 2 Tab 3
This is a heading inside Tab 3
Lorem ipsum dolor sit amet consect etuer adipi
scing elit sed diam nonumm...
Tab 1 Tab 2 Tab 3
This is a heading inside Tab 3
Lorem ipsum dolor sit amet consect etuer adipi
scing elit sed diam nonumm...
Tab 1 Tab 2 Tab 3
This is a heading inside Tab 3
Lorem ipsum dolor sit amet consect etuer adipi
scing elit sed diam nonumm...
Where to put
focus for
panels?
Ideally, focus should be placed
on the panel itself after
moving off the relevant tab
above. This also allows us to
announc...
Tab 1 Tab 2 Tab 3
This is a heading inside Tab 1
Lorem ipsum dolor sit amet consect etuer adipi
scing elit sed diam nonumm...
Focus can then move to any
focusable items inside the
panel as needed.
Tab 1 Tab 2 Tab 3
This is a heading inside Tab 1
Lorem ipsum dolor sit amet consect etuer adipi
scing elit sed diam nonumm...
What about
markup?
We can start with a basic list
and a series of <div> elements
below.
<!-­‐-­‐  In-­‐page-­‐tabs  -­‐-­‐>      
<ul>  
   <li><a  href="#panel1">Apple</a></li>  
   <li><a  href="#panel1">Pear...
We can then use WAI ARIA to
define the role or purpose of
each element.
<!-­‐-­‐  tablist  applied  to  UL  -­‐-­‐>      
<ul  role="tablist">  
</ul>
<!-­‐-­‐  presentation  applied  to  LI  -­‐-­‐>      
<ul  role="tablist">  
   <li  role="presentation">  
   </li>  
  ...
<!-­‐-­‐  tabs  applied  to  tabs  -­‐-­‐>      
<ul  role="tablist">  
   <li  role="presentation">  
   <a  href="#panel...
<!-­‐-­‐  tabpanel  applied  to  panels  -­‐-­‐>      
<div  id="panel1"  role="tabpanel">  
   Panel  1  
</div>  
<div  ...
Next up, we need to define
the controls for the tab panels
- using aria-controls.
<!-­‐-­‐  relating  panels  to  tabs  -­‐-­‐>      
<a  href="#panel1"  role="tab"  aria-­‐
controls="panel1">Apple</a>  
...
We also need to add labels to
the tab panels using aria-
labelledby.
<!-­‐-­‐  relating  tabs  to  panels  -­‐-­‐>      
<a  href="#panel1"  role="tab"  aria-­‐
controls="panel1"  id="tab1">A...
Now, we need to set the
various states for the tabs
using aria-selected=“true” (if
the user has selected this tab)
or aria...
<!-­‐-­‐  selected  tab  -­‐-­‐>      
<a  href="#panel1"  role="tab"  aria-­‐
controls="panel1"  aria-­‐selected="true"  ...
And the various states for the
tabs panels using aria-hidden
and aria-expanded.
<!-­‐-­‐  active  panel  -­‐-­‐>      
<div  role="tabpanel"  aria-­‐hidden="false"  
aria-­‐expanded="true"  aria-­‐label...
And now to set focus on the
relevant elements.
<!-­‐-­‐  active  tab  -­‐-­‐>      
<a  href="#panel1"  role="tab"  aria-­‐
controls="panel1"  aria-­‐selected="true"  
t...
JavaScript can be used to
swap these various option as
needed.
Breakdown
<!-­‐-­‐  active  tabs  -­‐-­‐>      
<a    
   href="#panel1"    
   role="tab"    
   aria-­‐controls="panel1"    
   ar...
<!-­‐-­‐  inactive  tabs  -­‐-­‐>      
<a    
   href="#panel1"    
   role="tab"    
   aria-­‐controls="panel1"    
   ...
<!-­‐-­‐  active  panels  -­‐-­‐>      
<div  
   role="tabpanel"    
   aria-­‐hidden="false"  
   aria-­‐expanded="true"...
<!-­‐-­‐  inactive  panels  -­‐-­‐>      
<div    
   role="tabpanel"    
   aria-­‐hidden="true"  
   aria-­‐expanded="fa...
OK, that was
intense, but you
don’t have to do
all of it
Moving forward
https://www.flickr.com/photos/kakissel/5484265811
Don’t be
overwhelmed.
Look for quick
wins.
You’ll be surprised
what you can do
without too many
tears.
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
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...
Get busy & have fun!
Russ Weakley
Max Design

Site: maxdesign.com.au

Twitter: twitter.com/russmaxdesign

Slideshare: slideshare.net/maxdesign
...
Upcoming SlideShare
Loading in …5
×

Building accessible web components without tears

4,558 views

Published on

Slides from #Respond16, Sydney Melbourne 2016

So, you've built an amazing new web application. It uses all the latest frameworks and libraries. It's beautiful to behold.

But is it accessible? Many web applications these days are built on top of pre-existing frameworks or code bases and there is little thought to how well these components will work for different assistive devices.

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, drop-down menus, in-page tabs and other commonly used we components. You will leave this talk ready and eager to enhance your application, and in the process, make it available to entirely new audiences.

Published in: Education

Building accessible web components without tears

  1. 1. without tears Building accessible web components
  2. 2. Four painful questions
  3. 3. Have you ever tried to navigate through your web site or application using the keyboard only (no mouse)? 1
  4. 4. Were you able to perform all the site/application tasks without issues? 2
  5. 5. As you navigated through the application using keyboard only, could you always see the element that was in focus? 3
  6. 6. Was tab order in a logical order (that reflected the on- screen order) or did focus jump all around the page? 4
  7. 7. The myth of “Full stack”
  8. 8. Over the last 5 years, 
 there seems to have been 
 a major change in front end development.
  9. 9. Developers are now being asked to be fluent in all sorts of libraries and frameworks - to be “full stack” developers.
  10. 10. But many “full stack” developers seem to have forgotten some of the core web principles…
  11. 11. Like… understanding basic HTML, CSS, accessibility, and using progressive enhancement.
  12. 12. “Why can’t I wrap a span around a div?”
  13. 13. Web accessibility begins with semantic markup
  14. 14. https://www.flickr.com/photos/tinto/16027598548 Why should I care?
  15. 15. One of our core roles as web professionals is making sure our sites /applications can be used by the widest possible audience.
  16. 16. This means everyone, including people with disabilities that include: Visual, Auditory, Motor skill and Cognitive
  17. 17. This also means making our sites and apps accessible for Assistive Technologies:
  18. 18. Input devices: 
 Accessible keyboards, Track pads, Head wands, Puffers, Switches, Touch screens, Voice activation software, etc.
  19. 19. Output devices: 
 Text-based browsers, Screen Readers, Magnifiers, Refreshable Braille Devices etc.
  20. 20. Assistive Technologies are more than just screen readers
  21. 21. Don’t panic!
  22. 22. All of this may sound time consuming and costly, but it doesn’t have to be.
  23. 23. I'm going to talk about some quick things you can do to make some common application components more accessible.
  24. 24. I’ll be focussing on some components that often present major barriers to Assistive Technologies.
  25. 25. Online tests
  26. 26. I have a range of online tests available, which show how different assistive technologies work with application components. http://maxdesign.com.au/jobs/sample-accessibility/
  27. 27. WAI ARIA
  28. 28. WAI: Web Accessibility Initiative ARIA: Accessible Rich Internet Applications
  29. 29. WAI-ARIA defines a way to make web sites and web applications more accessible - especially advanced JavaScript-based components.
  30. 30. We can use HTML attributes to define the role, states and properties of specific HTML elements.
  31. 31. Roles: Is it a widget (menu, slider, progress bar etc.) or an important type of element (heading, region, table, form etc.)
  32. 32. <ul  role="menu">     ...   </ul>   <main  role="main">     ...   </main>
  33. 33. States: What is the current state of the widget? Is it checked, disabled etc.
  34. 34. <input  aria-­‐disabled="true"  type="text">   <input  aria-­‐checked="true"  type="radio">
  35. 35. Properties: What are the properties of the widget? Does it have live regions, does it have relationships with other elements, etc?
  36. 36. <button  aria-­‐label="Close  and  return  to   application">     Close   </button>   <a  href="#"  aria-­‐describedby="info1">     Purchase   </a>
  37. 37. ARIA allows us to make specific HTML elements more meaningful for ATs
  38. 38. Dynamic content
  39. 39. The problem
  40. 40. Well done! Your changes have been saved Inserted after page load
  41. 41. Adding content after the initial page has loaded can cause potential issues for screen readers.
  42. 42. 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.
  43. 43. 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.
  44. 44. A solution
  45. 45. The aria-live attribute allows us to notify screen readers when content is updated in specific areas of a page.
  46. 46. We can apply the aria-live attribute to any HTML element.
  47. 47. <div  aria-­‐live="polite">   </div>
  48. 48. 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.
  49. 49. The aria-live attribute can be used for any page regions that are likely to get updates after the initial page is loaded.
  50. 50. 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 Alert messages
  51. 51. Dynamic stock info
  52. 52. Sortable tables
  53. 53. Possible values
  54. 54. There are three possible values for aria-live: “off”, “polite” and “assertive”.
  55. 55. <div  aria-­‐live="off">   </div>
  56. 56. Assistive Technologies should not announce updates unless the assistive technology is currently focused on that region.
  57. 57. Should be used for information that is not critical for users to know about immediately.
  58. 58. <div  aria-­‐live="polite">   </div>
  59. 59. Assistive Technologies should announce updates at the next graceful opportunity (e.g. end of current sentence).
  60. 60. Should be used for warning notifications that users may need to know.
  61. 61. <div  aria-­‐live="assertive">   </div>  
  62. 62. Assistive Technologies should announce updates immediately.
  63. 63. Should only be used if the interruption is imperative for users to know immediately such as error alerts.
  64. 64. 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
  65. 65. aria-relevant
  66. 66. aria-relevant This attribute gives a hint about what types of changes are relevant and should be announced by Assistive Technologies.
  67. 67. <!-­‐-­‐  Insertion  of  nodes  into  the  live  region   should  be  considered  relevant  -­‐-­‐>   <div  aria-­‐relevant="additions">   </div>  
  68. 68. <!-­‐-­‐  Deletion  of  nodes  should  be  considered   relevant    -­‐-­‐>   <div  aria-­‐relevant="removals">   </div>  
  69. 69. <!-­‐-­‐  Changes  to  the  textual  content  of   existing  nodes  should  be  considered  relevant   -­‐-­‐>   <div  aria-­‐relevant="text">   </div>  
  70. 70. <!-­‐-­‐  All  changed  nodes  should  be  considered   relevant  -­‐-­‐>   <div  aria-­‐relevant="all">   </div>  
  71. 71. The default behaviour is equivalent to “additions text”.
  72. 72. aria-relevant values of “removals” or “all” should be used sparingly.
  73. 73. role=alert
  74. 74. role=“alert” Defines a message with important information.
  75. 75. <div  role="alert">   </div>  
  76. 76. Elements with the role=“alert” have an implicit aria-live value of “assertive”.
  77. 77. aria-live: easy to apply, major benefits
  78. 78. Accessible Errors https://www.pexels.com/photo/animal-dog-pet-sad-7289/
  79. 79. Screen reader modes
  80. 80. It is important to understand that Screen Reader users generally read and interact with web pages in two main ways:
  81. 81. ‘Read’ mode: Users can read and navigate the page but can not enter data into form controls.
  82. 82. ‘Form’ mode: User can enter data into form controls. Keyboard access is restricted to page elements that can accept focus.
  83. 83. These days, screen readers will automatically switch between these two modes - though users can manually trigger these modes as needed.
  84. 84. Why do these two modes matter?
  85. 85. If a screen reader is in forms mode, content that is not directly associated with form controls may not be announced.
  86. 86. <!-­‐-­‐  this  error  message  may  not  be  announced   -­‐-­‐>   <div>     <label  for="email">Email</label>     <input  type="email"  id="email">     <p  class="error">Error</p>   </div>
  87. 87. Types of form validation
  88. 88. We’re going to look at two different aspects of client- side form validation.
  89. 89. 1. Form control validation Individual form fields are validated as the user moves focus out of the form control.
  90. 90. 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.
  91. 91. The problem
  92. 92. 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.
  93. 93. 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.
  94. 94. Problem 2: Screen reader users are often not informed that the overall form contains errors.
  95. 95. 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.
  96. 96. A solution for form control validation
  97. 97. 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.
  98. 98. 2. Flagging form controls and associated labels should not use colour alone to signify errors.
  99. 99. 3. An error message should be displayed in close proximity to the relevant form control.
  100. 100. Error: The phone number must include a 10 digit number Phone
  101. 101. 4. The error message should be informative - it should provide information that will help users fill in the field correctly.
  102. 102. 5. The error message should be programmatically associated with the form control.
  103. 103. This means that the error message should be announced along with the relevant label information.
  104. 104. There are a range of different methods to programmatically associate error messages with form controls.
  105. 105. The simplest is to place the error message content inside the label.
  106. 106. <div>     <label  for="email">       Email       <input  type="email"  id="email">       <span  class="error">Error</span>     </label>   </div>  
  107. 107. A solution for on-submit form validation
  108. 108. If there are one or more form validation errors:
  109. 109. 1. An error message should appear at the top of the form alerting users that there are errors.
  110. 110. 2. Focus must be taken to the error message as soon as the user has attempted to submit for form.
  111. 111. 3. The error message should list all errors.
  112. 112. 4. Each error should ideally be a link that takes the user to the relevant form control.
  113. 113. 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
  114. 114. 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.
  115. 115. The form has two errors that must be completed before it can be submitted. View all errors
  116. 116. Markup for error messages
  117. 117. The error message container can exist on the page, even when non-active. However, it should not contain any content until triggered.
  118. 118. This container should be set with role=“alert”. This is used to communicate important information.
  119. 119. <div       class="error-­‐message-­‐container"       role="alert">   </div>
  120. 120. Optionally, the aria-live attribute can added with a value of “assertive” or “polite”.
  121. 121. <div       class="error-­‐message-­‐container"       role="alert"     aria-­‐live="polite">   </div>
  122. 122. This container can be set with tabindex value of “-1” so that it will not receive focus.
  123. 123. <div       class="error-­‐message-­‐container"       role="alert"     aria-­‐live="polite"     tabindex="-­‐1">   </div>
  124. 124. 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.
  125. 125. If present, the tabindex attribute value needs to be changed from “-1” to “0” so that the element will appear in normal tab order.
  126. 126. <div     class="error-­‐message-­‐container"     role="alert"     aria-­‐live="polite"     tabindex="0">   </div>  
  127. 127. The container can be given a label so that it is announced to screen reader users.
  128. 128. <div     class="error-­‐message-­‐container"     role="alert"     aria-­‐live="polite"     tabindex="0"     aria-­‐label="Form  Errors">   </div>  
  129. 129. Accessible form errors: simple solutions, major benefits.
  130. 130. Accessible modals
  131. 131. The problem
  132. 132. 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.
  133. 133. Problem 2: Screen reader users are sometimes not informed that an action will trigger a modal.
  134. 134. 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.
  135. 135. 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.
  136. 136. A solution
  137. 137. 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.
  138. 138. <div     style="display:none">     ...   </div>  
  139. 139. When a modal window is triggered, we need to change the value.
  140. 140. <div     style="display:block">     ...   </div>  
  141. 141. When the modal window becomes active, all other content should be hidden from Assistive Technologies.
  142. 142. <!-­‐-­‐  all  other  content  -­‐-­‐>   <div     aria-­‐hidden="true">     ...   </div>   <!-­‐-­‐  modal  window  -­‐-­‐>   <div     style="display:block">     ...   </div>  
  143. 143. We need to set the initial focus to the modal window element itself rather than elements inside the modal.
  144. 144. Initial focus
  145. 145. Initial focus
  146. 146. This is important because we are going to give the modal a label.
  147. 147. If we set focus on an element inside the window, the label will not be announced to Assistive Technologies.
  148. 148. We need to inform screen reader users that this modal window is a “modal dialog”.
  149. 149. <div     style="display:block"     role="dialog">     ...   </div>
  150. 150. We need to provide a label for the modal dialog, so Assistive Technologies can announce its purpose.
  151. 151. <div     style="display:block"     role="dialog"     aria-­‐labelledby="modal-­‐label">     <h1  id="modal-­‐label">Choose  account</h1>   </div>  
  152. 152. In some circumstances, we may need to provide a more detailed description of the purpose of the modal dialog.
  153. 153. <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>  
  154. 154. Keystrokes
  155. 155. TAB
  156. 156. TAB
  157. 157. TAB
  158. 158. TAB
  159. 159. TAB
  160. 160. TAB
  161. 161. TAB
  162. 162. TAB
  163. 163. SHIFT + TAB
  164. 164. SHIFT + TAB
  165. 165. SHIFT + TAB
  166. 166. SHIFT + TAB
  167. 167. SHIFT + TAB
  168. 168. SHIFT + TAB
  169. 169. SHIFT + TAB
  170. 170. ENTER
  171. 171. ENTER
  172. 172. SPACE
  173. 173. SPACE
  174. 174. TAB
  175. 175. ARROW
  176. 176. Option 1 - apples ARROW
  177. 177. Option 2 - pears ARROW
  178. 178. Option 3 - bananas ARROW
  179. 179. ESC
  180. 180. Adding meaning to important actions
  181. 181. For some important actions inside the modal window, Assistive Technologies should be given additional information to let them know what will happen.
  182. 182. As screen reader users are submitting form data, they should be informed that:
  183. 183. 1. They will be taken back to the parent page.
  184. 184. 2. Where this data will be submitted when they return to the parent page.
  185. 185. ENTER “Submit and return to bank balance information. Your data will be added to the Balance table”
  186. 186. As screen reader users focus on the “Close” function, they should be informed that closing will take them back to the parent page.
  187. 187. ENTER “Leave form and return to bank balance information”
  188. 188. After modal dialog closes
  189. 189. When the modal window is closed, if users are being taken back to the parent page:
  190. 190. 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.
  191. 191. The user should not be thrown back to the top of the parent page unless there is a good reason!
  192. 192. 2. The user should be informed where they are and what change has occurred.
  193. 193. ENTER
  194. 194. 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”
  195. 195. Modals are a pain, but we can make them less painful
  196. 196. Accessible tabs https://www.flickr.com/photos/quandc/16426960180
  197. 197. The problem
  198. 198. In-page tabs can present issues for screen reader as well as keyboard-only users.
  199. 199. Problem 1: Screen reader users are often confused by the relationship between tabs and panels.
  200. 200. Problem 2: Keyboard-only users are often unable to navigate through the tabs and panels simply or intuitively.
  201. 201. A solution
  202. 202. The preferred keyboard-only navigation method for in- page tabs uses TAB keystrokes to move onto the active tab and active panel, and ARROW keys to move across tabs.
  203. 203. “TAB & ARROW”: Straight through pass
  204. 204. Tab 1 Tab 2 Tab 3 This is a heading inside Tab 1 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. This is a link inside tab 1. This is a link above the tabs This is a link below the tabs TAB
  205. 205. Tab 1 Tab 2 Tab 3 This is a heading inside Tab 1 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. This is a link inside tab 1. This is a link above the tabs This is a link below the tabs TAB
  206. 206. Tab 1 Tab 2 Tab 3 This is a heading inside Tab 1 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. This is a link inside tab 1. This is a link above the tabs This is a link below the tabs TAB
  207. 207. Tab 1 Tab 2 Tab 3 This is a heading inside Tab 1 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. This is a link inside tab 1. This is a link above the tabs This is a link below the tabs TAB
  208. 208. Tab 1 Tab 2 Tab 3 This is a heading inside Tab 1 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. This is a link inside tab 1. This is a link above the tabs This is a link below the tabs TAB
  209. 209. “TAB & ARROW”: Across the tabs pass
  210. 210. Tab 1 Tab 2 Tab 3 This is a heading inside Tab 1 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. This is a link inside tab 1. This is a link above the tabs This is a link below the tabs TAB
  211. 211. Tab 1 Tab 2 Tab 3 This is a heading inside Tab 2 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. This is a link inside tab 2. This is a link above the tabs This is a link below the tabs ARROW
  212. 212. Tab 1 Tab 2 Tab 3 This is a heading inside Tab 3 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. This is a link inside tab 3. This is a link above the tabs This is a link below the tabs ARROW
  213. 213. Tab 1 Tab 2 Tab 3 This is a heading inside Tab 3 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. This is a link inside tab 3. This is a link above the tabs This is a link below the tabs TAB
  214. 214. Tab 1 Tab 2 Tab 3 This is a heading inside Tab 3 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. This is a link inside tab 3. This is a link above the tabs This is a link below the tabs TAB
  215. 215. Tab 1 Tab 2 Tab 3 This is a heading inside Tab 3 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. This is a link inside tab 3. This is a link above the tabs This is a link below the tabs TAB
  216. 216. Where to put focus for panels?
  217. 217. Ideally, focus should be placed on the panel itself after moving off the relevant tab above. This also allows us to announce the panel to screen reader users.
  218. 218. Tab 1 Tab 2 Tab 3 This is a heading inside Tab 1 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. This is a link inside tab 1. This is a link above the tabs This is a link below the tabs TAB
  219. 219. Focus can then move to any focusable items inside the panel as needed.
  220. 220. Tab 1 Tab 2 Tab 3 This is a heading inside Tab 1 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. This is a link inside tab 1. This is a link above the tabs This is a link below the tabs TAB
  221. 221. What about markup?
  222. 222. We can start with a basic list and a series of <div> elements below.
  223. 223. <!-­‐-­‐  In-­‐page-­‐tabs  -­‐-­‐>       <ul>     <li><a  href="#panel1">Apple</a></li>     <li><a  href="#panel1">Pears</a></li>     <li><a  href="#panel1">Oranges</a></li>   </ul>   <div  id="panel1">Panel  1</div>   <div  id="panel1">Panel  2</div>   <div  id="panel1">Panel  3</div>
  224. 224. We can then use WAI ARIA to define the role or purpose of each element.
  225. 225. <!-­‐-­‐  tablist  applied  to  UL  -­‐-­‐>       <ul  role="tablist">   </ul>
  226. 226. <!-­‐-­‐  presentation  applied  to  LI  -­‐-­‐>       <ul  role="tablist">     <li  role="presentation">     </li>     <li  role="presentation">     </li>     <li  role="presentation">     </li>   </ul>
  227. 227. <!-­‐-­‐  tabs  applied  to  tabs  -­‐-­‐>       <ul  role="tablist">     <li  role="presentation">     <a  href="#panel1"  role="tab">Apple</a>     </li>     <li  role="presentation">     <a  href="#panel2"  role="tab">Pears</a>     </li>     <li  role="presentation">     <a  href="#panel3"  role="tab">Oranges</a>     </li>   </ul>
  228. 228. <!-­‐-­‐  tabpanel  applied  to  panels  -­‐-­‐>       <div  id="panel1"  role="tabpanel">     Panel  1   </div>   <div  id="panel1"  role="tabpanel">     Panel  2   </div>   <div  id="panel1"  role="tabpanel">     Panel  3   </div>  
  229. 229. Next up, we need to define the controls for the tab panels - using aria-controls.
  230. 230. <!-­‐-­‐  relating  panels  to  tabs  -­‐-­‐>       <a  href="#panel1"  role="tab"  aria-­‐ controls="panel1">Apple</a>   <div  role="tabpanel"  id="panel1">
  231. 231. We also need to add labels to the tab panels using aria- labelledby.
  232. 232. <!-­‐-­‐  relating  tabs  to  panels  -­‐-­‐>       <a  href="#panel1"  role="tab"  aria-­‐ controls="panel1"  id="tab1">Apple</a>   <div  role="tabpanel"  aria-­‐labelledby="tab1"   id="panel1">  
  233. 233. Now, we need to set the various states for the tabs using aria-selected=“true” (if the user has selected this tab) or aria-selected=“false” (for all other tabs.
  234. 234. <!-­‐-­‐  selected  tab  -­‐-­‐>       <a  href="#panel1"  role="tab"  aria-­‐ controls="panel1"  aria-­‐selected="true"   id="tab1">Apple</a>   <!-­‐-­‐  inactive  tab  -­‐-­‐>       <a  href="#panel2"  role="tab"  aria-­‐ controls="panel2"  aria-­‐selected="false"   id="tab2">Pears</a>  
  235. 235. And the various states for the tabs panels using aria-hidden and aria-expanded.
  236. 236. <!-­‐-­‐  active  panel  -­‐-­‐>       <div  role="tabpanel"  aria-­‐hidden="false"   aria-­‐expanded="true"  aria-­‐labelledby="tab1"   id="panel1">   <!-­‐-­‐  inactive  panel  -­‐-­‐>       <div  role="tabpanel"  aria-­‐hidden="true"   aria-­‐expanded="false"  aria-­‐labelledby="tab2"   id="panel2">  
  237. 237. And now to set focus on the relevant elements.
  238. 238. <!-­‐-­‐  active  tab  -­‐-­‐>       <a  href="#panel1"  role="tab"  aria-­‐ controls="panel1"  aria-­‐selected="true"   tabindex="0"  id="tab1">Apple</a>   <!-­‐-­‐  inactive  tab  -­‐-­‐>       <a  href="#panel2"  role="tab"  aria-­‐ controls="panel2"  aria-­‐selected="false"   tabindex="-­‐1"  id="tab2">Pears</a>
  239. 239. JavaScript can be used to swap these various option as needed.
  240. 240. Breakdown
  241. 241. <!-­‐-­‐  active  tabs  -­‐-­‐>       <a       href="#panel1"       role="tab"       aria-­‐controls="panel1"       aria-­‐selected="true"       tabindex="0"     id="tab1">Apple</a>
  242. 242. <!-­‐-­‐  inactive  tabs  -­‐-­‐>       <a       href="#panel1"       role="tab"       aria-­‐controls="panel1"       aria-­‐selected="false"       tabindex="-­‐1"     id="tab1">Apple</a>
  243. 243. <!-­‐-­‐  active  panels  -­‐-­‐>       <div     role="tabpanel"       aria-­‐hidden="false"     aria-­‐expanded="true"     aria-­‐labelledby="tab1"       id="panel1"       class="panel">
  244. 244. <!-­‐-­‐  inactive  panels  -­‐-­‐>       <div       role="tabpanel"       aria-­‐hidden="true"     aria-­‐expanded="false"     aria-­‐labelledby="tab1"       id="panel1"       class="panel">  
  245. 245. OK, that was intense, but you don’t have to do all of it
  246. 246. Moving forward https://www.flickr.com/photos/kakissel/5484265811
  247. 247. Don’t be overwhelmed. Look for quick wins.
  248. 248. You’ll be surprised what you can do without too many tears.
  249. 249. Test with keyboard-only and make changes as needed. (Make sure you also check for visible focus). 1
  250. 250. /*  avoid  this!  */   :focus  {  outline:  none;  }
  251. 251. Test with accessibility checking tools and make changes as needed.2
  252. 252. 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/
  253. 253. 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/
  254. 254. Test with one or more screen readers and make changes as needed.3
  255. 255. 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
  256. 256. Get expert assistance and conduct a formal accessibility audit of your website or web application and action as needed. 4
  257. 257. When is the best time to focus on accessibility?
  258. 258. The best time to focus on accessibility is right at the beginning of development process, when creating the individual components in your pattern library.
  259. 259. Get busy & have fun!
  260. 260. Russ Weakley Max Design Site: maxdesign.com.au Twitter: twitter.com/russmaxdesign Slideshare: slideshare.net/maxdesign Linkedin: linkedin.com/in/russweakley

×