Embed Size (px)
Citation preview
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
Passions:
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 accessibility APIs available.
<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 how the ARIA attributes work.
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, 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/
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
different levels of skill.
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
screen reader users.
Purchase
This “Purchase” link may be acceptable for sighted users who can see the link in context and
do not require additional information.
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
PASS
PASS
-
-
-
Voiceover
-
-
-
-
FAIL
FAIL
PASS
<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
PASS
PASS
-
-
-
Voiceover
-
-
-
-
PASS
PASS
PASS
<a href="#" aria-‐labelledby="info1"> Purchase </a> <p id="info1" class="hidden"> Don Quixote by Miguel De Cervantes </p>
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
<a href="#" aria-‐describedby="info1"> Purchase </a> <p id="info1" class="hidden"> Purchase Don Quixote by Miguel De Cervantes </p>
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
<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
PASS
PASS
-
-
-
Voiceover
-
-
-
-
PASS
PASS
PASS
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-to-links.html
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
PASS
PASS
-
-
-
Voiceover
-
-
-
-
FAIL
FAIL
FAIL
<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
PASS
PASS
-
-
-
Voiceover
-
-
-
-
PASS
PASS
PASS
<a href="#" aria-‐labelledby="info1"> Close </a> <p id="info1" class="hidden"> and return to Account details </p>
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
<button aria-‐describedby="info1"> Close </button> <p id="info1" class="hidden"> and return to Account details </p>
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
<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
PASS
PASS
-
-
-
Voiceover
-
-
-
-
PASS
PASS
PASS
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-adding-to-buttons.html
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-screen - for links and buttons.
AED $10,640.00
For example, “AED” may be acceptable for sighted users but may not make sense for screen reader users - especially when
out of context.
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 Arab Emirates Dirham </span> </a>
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
More information at “Display A, announce B - link content”:
http://maxdesign.com.au/jobs/sample-accessibility/06-context/03-different-content-link.html
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
PASS
PASS
-
-
-
Voiceover
-
-
-
-
PASS
PASS
PASS
More information at “Display A, announce B - button
content”:
http://maxdesign.com.au/jobs/sample-accessibility/06-context/04-different-content-button.html
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 up by the screen reader.
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.
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 changes within that element.
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 alerts! Fix the error and try again
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://maxdesign.com.au/jobs/sample-accessibility/10-notifications/index.html
aria-relevant
aria-relevant This attribute gives a hint about
what types of changes are relevant and should be announced by Assistive
Technologies.
<!-‐-‐ Insertion of nodes into the live region should be considered relevant -‐-‐> <div aria-‐relevant="additions"> </div>
<!-‐-‐ 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 aria-‐relevant="text"> </div>
<!-‐-‐ 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
to the server.
The problem
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.
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.
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 reader users have no idea why the form won’t submit.
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 aware that there is an
error.
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</span> </label> </div>
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 name2. Error: Email address must include an "@" symbol
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.
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
triggered.
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">
</div>
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.
If present, the tabindex attribute value needs to be changed from “-1” to “0” so that the element will appear in normal tab order.
<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-‐label="Form Errors">
</div>
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 be very confusing and disconcerting.
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 perform within the modal.
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.
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 -‐-‐> <div style="display:block"> ... </div>
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">Choose account</h1>
</div>
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-‐description">
<h1 id="modal-‐label">Choose account</h1> <p id="modal-‐description"> Description here </p>
</div>
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 - applesARROW
Option 2 - pearsARROW
Option 3 - bananasARROW
ESC
Adding meaning to important actions
For some important actions inside the modal window,
Assistive Technologies should be given additional
information to let them know what will happen.
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 parent page.
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 element that invoked the dialog.
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 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”
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 components in your
pattern library.
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://www.paciellogroup.com/resources/aviewer
Colour Contrast Analyser https://www.paciellogroup.com/resources/contrastanalyser/
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/
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
-
-
-
JAWS
PASS/FAIL
PASS/FAIL
PASS/FAIL
PASS/FAIL
-
-
-
Voiceover
-
-
-
-
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.auTwitter: twitter.com/russmaxdesignSlideshare: slideshare.net/maxdesignLinkedin: linkedin.com/in/russweakley
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-‐default" type="button"> Button using a button </button>
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
specific ways.
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.
