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

Autocomplete
Building an
What is
Autocomplete?
“Autocomplete” is a software
function that provides relevant
suggestions based on input by the
user.
For this presentation, we’re going to
focus on accessible autocomplete
associated with search.
Search towns in Australia
ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing autosuggest search compo...
The aim is to provide some
information to consider if you’re
thinking about building an
accessible autocomplete search.
User Experience
Before diving into accessibility, 

we’ll look at some common UX
patterns associated with
autocomplete search.
1. There should be clear wording or
visual indicators to describe the
purpose of the search.
For example, are users searching
across the entire site, an aspect of
the site, or is it a specific search
function?
Search towns in Australia
Diagram showing highlighted label “Search towns in Australia”
2. If additional instructions are
required, they should be located in
close proximity to the field.
Diagram showing information under the input “You can filter by Town or by State”
Search towns in Australia
You can filter b...
3. The placeholder attribute
should not be used for complex
instructions.
This attribute it is often displayed in
a faint colour which fails WCAG
colour contrast guidelines.
It is also wiped as soon as the
user begins typing so instructions
become unavailable.
Search
Search Towns in Australia
Diagram showing placeholder “Search towns in Australia” with red cross beside placeholder
4. The list of autocomplete
suggestions could highlight the
string typed by the user.
Search towns in Australia
ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing autosuggest options high...
Or, the list could the highlight
everything apart from the string
typed by the user.
Search towns in Australia
ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing autosuggest options high...
Both of these methods are
beneficial as they help users
understand the relationship
between their string and the
resulting ...
5. Users should be able to quickly
identify what type of strings will
trigger the autocomplete?
Does the search work based on the
initial characters of suggestions…
Search towns in Australia
ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing autosuggest options high...
Or any characters within the
suggestion?
Search towns in Australia
ara
Araluen, NSW
Bargara, QLD
Bingara, NSW
Coonabarabran, NSW
Diagram showing autosuggest option...
6. Any autocomplete suggestions
should be accurate.
Users should not be presented with
suggestions that do not match
their typed strings.
Search towns in Australia
Banana
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing autosuggest options ...
7. Users should be able to easily
clear the search form of previously
typed strings.
Search towns in Australia
Adaminaby, NSW
Diagram showing highlighted clear component
8. Ideally, there should be some
clearly defined submit action
associated with the search.
Diagram showing highlighted submit component
Search towns in Australia
Adaminaby, NSW
Some search functions return “live
filtering results”. These are results
that dynamically change as the
user types.
In these cases, a submit button may
seem redundant as there is nothing
to submit.
However, Screen Reader users may
not be aware that their typed strings
have already delivered a result in a
different area ...
While it’s possible to inform users
that changes have occurred, a
submit button is an easy method to
get around this probl...
Keyboard-only
Regardless of the method used to
build an auto-complete, it should be
accessible to keyboard-only
users.
Focus
Any web page or web app should
have clear visual indicators to help
keyboard-only users determine
which element is current...
This could just be the default
browser focus ring…
Diagram showing input in focus - indicated with blue focus ring
Search towns in Australia
Or using your own visual indicator
methodology.
Search towns in Australia
Diagram showing input in focus - indicated with black dotted lines
It should never be hard or
impossible for keyboard-only users
to see what is in focus.
/* Bad practice */
input:focus {
outline: none;
}
Ideally, the visual indicator
methodology should be consistent
across all focusable elements.
Users should not have to learn
different visual indicators just to
understand what is currently in
focus.
Keystrokes
Keyboard-only users should be able
to perform any of the following
actions…
1. Use the TAB keystroke to move
focus into the search input field
from a previous element with focus.
Search towns in Australia
Diagram showing input in focus
TAB
2. Use the TAB keystroke to move
focus from the search input to the
“clear” button.
Search towns in Australia
Adaminaby, NSW
Diagram showing clear button in focus
TAB
3. Use the ENTER keystroke to
trigger the “clear” button.
Search towns in Australia
Adaminaby, NSW
Diagram showing selected clear button
ENTER
Note: When the “clear” button has
been triggered, the search input
field should be cleared and focus
should shift to this fi...
Search towns in Australia
Diagram showing focus move for clear button back to search input
4. Use the TAB keystroke to move
focus from the clear button to the
submit button.
Adaminaby, NSW
Search towns in Australia
Diagram showing focus move form the clear button to the submit button
TAB
5. Use the ENTER keystroke to
trigger the submit button.
Search towns in Australia
Adaminaby, NSW
Diagram showing selected submit button
ENTER
Note: When the submit button has
been triggered, focus should shift
to the search result area below the
autocomplete searc...
Diagram showing focus move from submit button to search results
Search towns in Australia
Search Results
Bell, NSW
Bell is...
6. Use the DOWN ARROW keystroke to
move focus from the search input
field to the first item in list of
autocomplete suggesti...
Search towns in Australia
ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing focus move from input to...
7. Use the UP ARROW and DOWN
ARROW keystrokes to navigate
backwards and forwards through
suggestions.
Search towns in Australia
ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing second selection in focu...
Note: The autosuggest item in focus
should always be in view if there is
a scrolling mechanism in place.
8: Users should not be able to DOWN
ARROW past the last suggestion
option.
Search towns in Australia
ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing last selection in focus ...
9. Some developers allow DOWN
ARROW keystrokes to loop from the
last suggestion directly back to the
initial input box.
However, I have found that some
users find this confusing. They
may not be aware that they have
returning to the input field.
Search towns in Australia
ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing last selection in focus ...
10. However, users should be able
to UP ARROW from the first
suggestion back into the search
input field.
Search towns in Australia
ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing focus move from autosugg...
11. Use the ENTER keystrokes to
select an autocomplete
suggestion.
Search towns in Australia
ar
Arltunga, NT
Armadale, WA
Armidale, NSW
Arno Bay, SA
Diagram showing selected suggest option
...
Note: When the ENTER keystroke
has been triggered, focus should
shift back to the search input
field.
Search towns in Australia
Armadale, WA
Diagram showing focus move from selected suggestion to search input field
12. Use the ESC keystroke to close
the suggestion list and return
focus to the initial input (i.e. if none
of the suggesti...
Search towns in Australia
ar
Diagram showing focus returning to input
ESC
Markup for screen
readers
There are a wide range of different
ways to mark up an accessible
auto-suggest widget. Here are
some suggestions.
A quick overall view of the
markup components
The widget should be wrapped
inside a <form> element.
<form action="#">
</form>
The <label> and <input>
elements are the core of the search
button.
<form action="#">
<label></label>
<input>
</form>
In our example, one <button>
element will be used to “clear” user
input.
<form action="#">
<label></label>
<input>
<button></button>
</form>
And a second <button> element
will be used to submit the form.
<form action="#">
<label></label>
<input>
<button></button>
<button></button>
</form>
The <ul> allows us to display the
list of suggestions when
appropriate.
<form action="#">
<label></label>
<input>
<button></button>
<button></button>
<ul>
<li></li>
<li></li>
<li></li>
</ul>
</f...
The <div> element allows us to
provide hidden instructions for
screen reader users.
<form action="#">
<label></label>
<input>
<button></button>
<button></button>
<ul>
<li></li>
<li></li>
<li></li>
</ul>
<di...
FOR and ID attributes
In order to explicitly associate 

the <label> element with the
<input> element, we should use 

for and id attributes.
<label for="search">Search towns in Australia</label>
<input
id="search"
type="text"
aria-describedby="instructions"
aria-...
TYPE attribute
The <input> element’s type
attribute could be set to a value of
"text" or "search".
<label for="search">Search towns in Australia</label>
<input
id="search"
type="text"
aria-describedby="instructions"
aria-...
<label for="search">Search towns in Australia</label>
<input
id="search"
type="search"
aria-describedby="instructions"
ari...
However, it is important to consider
how the “clear” button will
operate.
Some browsers, like Chrome and
Safari will display an <input> type
of "search" with a native “clear”
button at the right s...
Chrome
Firefox
Safari
Diagram showing Chrome and Safari’s clear button. Firefox has no clear button.
More importantly, this native “clear”
button often cannot be accessed
via the TAB keystroke, so it is
inaccessible for man...
So, if you want to use a robust and
accessible “clear” button, it is
better to use a separate <button>
element.
Using CSS, you can make the clear
button look like it sits inside the
<input> element.
Diagram showing three different elements - the input, the clear and the submit button
Search towns in Australia
Search town...
Then make sure to set the type to
"text" rather than "search".
<label for="search">Search towns in Australia</label>
<input
id="search"
type="text"
aria-describedby="instructions"
aria-...
ARIA-DESCRIBEDBY
attribute
The aria-describedby attribute
allows us to describe the purpose
of the current element. It points the
current element to ...
<label for="search">Search towns in Australia</label>
<input
id="search"
type="text"
aria-describedby="instructions"
aria-...
This allows us to provide basic
instructions on the use of the
widget for assistive technologies.
<div id="instructions" aria-live="assertive"
style="display: none;">
When autocomplete options are available, use up and d...
ARIA-OWNS attribute
The aria-owns attribute allows us
to define “a parent/child
contextual relationship to assistive
technologies that is other...
In other words, we can define the
<input> element as the parent, and
the <ul> element as the child
element.
<label for="search">Search towns in Australia</label>
<input
id="search"
type="text"
aria-describedby="instructions"
aria-...
ARIA-EXPANDED attribute
The aria-expanded attribute allows
us to inform assistive technologies
when the autocomplete dropdown
is present. It is in...
<label for="search">Search towns in Australia</label>
<input
id="search"
type="text"
aria-describedby="instructions"
aria-...
This value needs to dynamically
change to "true" as soon as the
autocomplete suggestions are
present.
<label for="search">Search towns in Australia</label>
<input
id="search"
type="text"
aria-describedby="instructions"
aria-...
Buttons
Directly after the input, we need two
<button> elements.
The first <button> should be a type
of "button" and allow users to
clear the input.
<button type="button" aria-label="Clear"></button>
<button type="submit" aria-label="Search"></button>
The second <button> should be a
type of "submit" and allow users to
submit the form.
<button type="button" aria-label="Clear"></button>
<button type="submit" aria-label="Search"></button>
You may want to use icons instead
of text for one or both of the
buttons. In this case we are using
“clear” and “search” i...
Search towns in Australia
Diagram showing clear and search icons
However, if you user icons instead
of text, you will need to provide
additional context for Assistive
Technologies.
In this case, we can use aria-
label attributes to provide hidden
labels for both buttons.
<button type="button" aria-label="Clear"></button>
<button type="submit" aria-label="Search"></button>
Unordered list
After the two button elements, we
need to add the <ul> element which
will be used to display the
autocomplete suggestions.
<ul
id="results"
role="listbox"
tabindex="-1"
style="display: none;"
>
<li role="option" aria-selected="false">apple</li>
...
As mentioned before, the ID
attribute’s value of "results"
allows us to determine that this
element is “owned” by the pare...
<ul
id="results"
role="listbox"
tabindex="-1"
style="display: none;"
>
<li role="option" aria-selected="false">apple</li>
...
The role attribute can be set with a
value of "listbox", which informs
assistive technologies that the
element is a widget...
<ul
id="results"
role="listbox"
tabindex="-1"
style="display: none;"
>
<li role="option" aria-selected="false">apple</li>
...
To make sure the element cannot
be brought into focus before it is
triggered, we can set the tabindex
attribute to "-1".
<ul
id="results"
role="listbox"
tabindex="-1"
style="display: none;"
>
<li role="option" aria-selected="false">apple</li>
...
This value needs to dynamically
change to "0" as soon as the
autocomplete suggestions are
present.
<ul
id="results"
role="listbox"
tabindex="0"
style="display: block;"
>
<li role="option" aria-selected="false">apple</li>
...
To make sure the element is initially
hidden we can set the style
attribute to "display:none".
<ul
id="results"
role="listbox"
tabindex="-1"
style="display: none;"
>
<li role="option" aria-selected="false">apple</li>
...
This value needs to dynamically
change to something like
"display:block" as soon as the
autocomplete options are triggered.
<ul
id="results"
role="listbox"
tabindex="0"
style="display: block;"
>
<li role="option" aria-selected="false">apple</li>
...
List items
Each of the <li> elements can be
given a role attribute with a value
of "option" with informs assistive
technologies that ...
<ul
id="results"
role="listbox"
tabindex="-1"
style="display: none;"
>
<li role="option" aria-selected="false">apple</li>
...
Each of the <li> elements needs to
have an aria-selected attribute
initially set to "false".
<ul
id="results"
role="listbox"
tabindex="-1"
style="display: none;"
>
<li role="option" aria-selected="false">apple</li>
...
This value needs to dynamically
change to "true" if the individual
option is selected.
<ul
id="results"
role="listbox"
tabindex="-1"
style="display: none;"
>
<li role="option" aria-selected="true">apple</li>
<...
The hidden DIV
After the <ul> element, we have the
<div> element, which has the
instructions for assistive
technologies.
<div
id="instructions"
class="off-left"
aria-live="assertive"
>
When autocomplete options are available, use up and down
a...
As mentioned before, the ID value
allows us to point the <input>
element to this <div> element via
the aria-describedby at...
<div
id="instructions"
class="off-left"
aria-live="assertive"
>
When autocomplete options are available, use up and down
a...
The <div> element needs to be
visually hidden, but still available to
screen readers.
This can be achieved by setting it
“off-left” using CSS. So, we can
give it a pretend “off-left” class here.
<div
id="instructions"
class="off-left"
aria-live="assertive"
>
When autocomplete options are available, use up and down
a...
The aria-live attribute is set to
"assertive". This informs assistive
technologies as soon as anything
inside this element...
<div
id="instructions"
class="off-left"
aria-live="assertive"
>
When autocomplete options are available, use up and down
a...
We need this because the
instructions will dynamically
change as soon as the
autocomplete options are triggered.
<div
id="instructions"
class="off-left"
aria-live="assertive"
>
When autocomplete results are available use up and down
ar...
<div
id="instructions"
class="off-left"
aria-live="assertive"
>
6 options available. Use up and down arrows to review and
...
The instructions should also
immediately change as users type
if the number of suggestions
changes.
<div
id="instructions"
class="off-left"
aria-live="assertive"
>
3 options available. Use up and down arrows to review and
...
The ideal method?
As mentioned before, this is just
one method that could be used.
Before deciding, make sure you
check out different methods and
test them - with real users, and
across different assistive
t...
Good examples
One of my favourite accessible
autocomplete search widgets is the
haltersweb version:

https://haltersweb.github.io/Access...
However, there are a wide range of
different solutions available, such as:

http://www.visionaustralia.org/digital-access-a...
Russ Weakley
Max Design
Site: maxdesign.com.au
Twitter: twitter.com/russmaxdesign
Slideshare: slideshare.net/maxdesign
Lin...
Upcoming SlideShare
Loading in …5
×

Building an accessible auto-complete - #ID24

702 views

Published on

This presentation will take a deep dive into how to create an auto-complete search function that is accessible to a range of different users including keyboard-only and screen reader users. Along the way, we will explore important keystrokes and aria attributes that can be used enhance the experience for all users.

Published in: Education
  • Be the first to comment

Building an accessible auto-complete - #ID24

  1. 1. Accessible
 Autocomplete Building an
  2. 2. What is Autocomplete?
  3. 3. “Autocomplete” is a software function that provides relevant suggestions based on input by the user.
  4. 4. For this presentation, we’re going to focus on accessible autocomplete associated with search.
  5. 5. Search towns in Australia ar Arltunga, NT Armadale, WA Armidale, NSW Arno Bay, SA Diagram showing autosuggest search component
  6. 6. The aim is to provide some information to consider if you’re thinking about building an accessible autocomplete search.
  7. 7. User Experience
  8. 8. Before diving into accessibility, 
 we’ll look at some common UX patterns associated with autocomplete search.
  9. 9. 1. There should be clear wording or visual indicators to describe the purpose of the search.
  10. 10. For example, are users searching across the entire site, an aspect of the site, or is it a specific search function?
  11. 11. Search towns in Australia Diagram showing highlighted label “Search towns in Australia”
  12. 12. 2. If additional instructions are required, they should be located in close proximity to the field.
  13. 13. Diagram showing information under the input “You can filter by Town or by State” Search towns in Australia You can filter by Town or by State
  14. 14. 3. The placeholder attribute should not be used for complex instructions.
  15. 15. This attribute it is often displayed in a faint colour which fails WCAG colour contrast guidelines.
  16. 16. It is also wiped as soon as the user begins typing so instructions become unavailable.
  17. 17. Search Search Towns in Australia Diagram showing placeholder “Search towns in Australia” with red cross beside placeholder
  18. 18. 4. The list of autocomplete suggestions could highlight the string typed by the user.
  19. 19. Search towns in Australia ar Arltunga, NT Armadale, WA Armidale, NSW Arno Bay, SA Diagram showing autosuggest options highlighting the user string
  20. 20. Or, the list could the highlight everything apart from the string typed by the user.
  21. 21. Search towns in Australia ar Arltunga, NT Armadale, WA Armidale, NSW Arno Bay, SA Diagram showing autosuggest options highlighting the non-user string
  22. 22. Both of these methods are beneficial as they help users understand the relationship between their string and the resulting options.
  23. 23. 5. Users should be able to quickly identify what type of strings will trigger the autocomplete?
  24. 24. Does the search work based on the initial characters of suggestions…
  25. 25. Search towns in Australia ar Arltunga, NT Armadale, WA Armidale, NSW Arno Bay, SA Diagram showing autosuggest options highlighting the user string at the start of each item
  26. 26. Or any characters within the suggestion?
  27. 27. Search towns in Australia ara Araluen, NSW Bargara, QLD Bingara, NSW Coonabarabran, NSW Diagram showing autosuggest options highlighting the user string within each item
  28. 28. 6. Any autocomplete suggestions should be accurate.
  29. 29. Users should not be presented with suggestions that do not match their typed strings.
  30. 30. Search towns in Australia Banana Arltunga, NT Armadale, WA Armidale, NSW Arno Bay, SA Diagram showing autosuggest options that do not match the user string ?
  31. 31. 7. Users should be able to easily clear the search form of previously typed strings.
  32. 32. Search towns in Australia Adaminaby, NSW Diagram showing highlighted clear component
  33. 33. 8. Ideally, there should be some clearly defined submit action associated with the search.
  34. 34. Diagram showing highlighted submit component Search towns in Australia Adaminaby, NSW
  35. 35. Some search functions return “live filtering results”. These are results that dynamically change as the user types.
  36. 36. In these cases, a submit button may seem redundant as there is nothing to submit.
  37. 37. However, Screen Reader users may not be aware that their typed strings have already delivered a result in a different area of the page.
  38. 38. While it’s possible to inform users that changes have occurred, a submit button is an easy method to get around this problem.
  39. 39. Keyboard-only
  40. 40. Regardless of the method used to build an auto-complete, it should be accessible to keyboard-only users.
  41. 41. Focus
  42. 42. Any web page or web app should have clear visual indicators to help keyboard-only users determine which element is currently in focus.
  43. 43. This could just be the default browser focus ring…
  44. 44. Diagram showing input in focus - indicated with blue focus ring Search towns in Australia
  45. 45. Or using your own visual indicator methodology.
  46. 46. Search towns in Australia Diagram showing input in focus - indicated with black dotted lines
  47. 47. It should never be hard or impossible for keyboard-only users to see what is in focus.
  48. 48. /* Bad practice */ input:focus { outline: none; }
  49. 49. Ideally, the visual indicator methodology should be consistent across all focusable elements.
  50. 50. Users should not have to learn different visual indicators just to understand what is currently in focus.
  51. 51. Keystrokes
  52. 52. Keyboard-only users should be able to perform any of the following actions…
  53. 53. 1. Use the TAB keystroke to move focus into the search input field from a previous element with focus.
  54. 54. Search towns in Australia Diagram showing input in focus TAB
  55. 55. 2. Use the TAB keystroke to move focus from the search input to the “clear” button.
  56. 56. Search towns in Australia Adaminaby, NSW Diagram showing clear button in focus TAB
  57. 57. 3. Use the ENTER keystroke to trigger the “clear” button.
  58. 58. Search towns in Australia Adaminaby, NSW Diagram showing selected clear button ENTER
  59. 59. Note: When the “clear” button has been triggered, the search input field should be cleared and focus should shift to this field again.
  60. 60. Search towns in Australia Diagram showing focus move for clear button back to search input
  61. 61. 4. Use the TAB keystroke to move focus from the clear button to the submit button.
  62. 62. Adaminaby, NSW Search towns in Australia Diagram showing focus move form the clear button to the submit button TAB
  63. 63. 5. Use the ENTER keystroke to trigger the submit button.
  64. 64. Search towns in Australia Adaminaby, NSW Diagram showing selected submit button ENTER
  65. 65. Note: When the submit button has been triggered, focus should shift to the search result area below the autocomplete search widget.
  66. 66. Diagram showing focus move from submit button to search results Search towns in Australia Search Results Bell, NSW Bell is a small rural and residential village in the Blue Mountains region of New South Wales. Bells Beach, VIC Bells Beach is a coastal locality of Victoria, Australia iand a renowned surf beach. Bell
  67. 67. 6. Use the DOWN ARROW keystroke to move focus from the search input field to the first item in list of autocomplete suggestions.
  68. 68. Search towns in Australia ar Arltunga, NT Armadale, WA Armidale, NSW Arno Bay, SA Diagram showing focus move from input to first suggestion ↓ARROW
  69. 69. 7. Use the UP ARROW and DOWN ARROW keystrokes to navigate backwards and forwards through suggestions.
  70. 70. Search towns in Australia ar Arltunga, NT Armadale, WA Armidale, NSW Arno Bay, SA Diagram showing second selection in focus and arrows to indicate focus can move backwards or forwards ↓ARROW ↑ARROW
  71. 71. Note: The autosuggest item in focus should always be in view if there is a scrolling mechanism in place.
  72. 72. 8: Users should not be able to DOWN ARROW past the last suggestion option.
  73. 73. Search towns in Australia ar Arltunga, NT Armadale, WA Armidale, NSW Arno Bay, SA Diagram showing last selection in focus and red cross to indicate focus cannot go forward ↓ARROW
  74. 74. 9. Some developers allow DOWN ARROW keystrokes to loop from the last suggestion directly back to the initial input box.
  75. 75. However, I have found that some users find this confusing. They may not be aware that they have returning to the input field.
  76. 76. Search towns in Australia ar Arltunga, NT Armadale, WA Armidale, NSW Arno Bay, SA Diagram showing last selection in focus and red cross to indicate focus cannot jump to search input ↓ARROW
  77. 77. 10. However, users should be able to UP ARROW from the first suggestion back into the search input field.
  78. 78. Search towns in Australia ar Arltunga, NT Armadale, WA Armidale, NSW Arno Bay, SA Diagram showing focus move from autosuggest dropdown to search input ↑ARROW
  79. 79. 11. Use the ENTER keystrokes to select an autocomplete suggestion.
  80. 80. Search towns in Australia ar Arltunga, NT Armadale, WA Armidale, NSW Arno Bay, SA Diagram showing selected suggest option ENTER
  81. 81. Note: When the ENTER keystroke has been triggered, focus should shift back to the search input field.
  82. 82. Search towns in Australia Armadale, WA Diagram showing focus move from selected suggestion to search input field
  83. 83. 12. Use the ESC keystroke to close the suggestion list and return focus to the initial input (i.e. if none of the suggestions are relevant).
  84. 84. Search towns in Australia ar Diagram showing focus returning to input ESC
  85. 85. Markup for screen readers
  86. 86. There are a wide range of different ways to mark up an accessible auto-suggest widget. Here are some suggestions.
  87. 87. A quick overall view of the markup components
  88. 88. The widget should be wrapped inside a <form> element.
  89. 89. <form action="#"> </form>
  90. 90. The <label> and <input> elements are the core of the search button.
  91. 91. <form action="#"> <label></label> <input> </form>
  92. 92. In our example, one <button> element will be used to “clear” user input.
  93. 93. <form action="#"> <label></label> <input> <button></button> </form>
  94. 94. And a second <button> element will be used to submit the form.
  95. 95. <form action="#"> <label></label> <input> <button></button> <button></button> </form>
  96. 96. The <ul> allows us to display the list of suggestions when appropriate.
  97. 97. <form action="#"> <label></label> <input> <button></button> <button></button> <ul> <li></li> <li></li> <li></li> </ul> </form>
  98. 98. The <div> element allows us to provide hidden instructions for screen reader users.
  99. 99. <form action="#"> <label></label> <input> <button></button> <button></button> <ul> <li></li> <li></li> <li></li> </ul> <div></div> </form>
  100. 100. FOR and ID attributes
  101. 101. In order to explicitly associate the <label> element with the <input> element, we should use for and id attributes.
  102. 102. <label for="search">Search towns in Australia</label> <input id="search" type="text" aria-describedby="instructions" aria-owns="results" aria-expanded="false" >
  103. 103. TYPE attribute
  104. 104. The <input> element’s type attribute could be set to a value of "text" or "search".
  105. 105. <label for="search">Search towns in Australia</label> <input id="search" type="text" aria-describedby="instructions" aria-owns="results" aria-expanded="false" >
  106. 106. <label for="search">Search towns in Australia</label> <input id="search" type="search" aria-describedby="instructions" aria-owns="results" aria-expanded="false" >
  107. 107. However, it is important to consider how the “clear” button will operate.
  108. 108. Some browsers, like Chrome and Safari will display an <input> type of "search" with a native “clear” button at the right side of the input. Other browses like Firefox, do not.
  109. 109. Chrome Firefox Safari Diagram showing Chrome and Safari’s clear button. Firefox has no clear button.
  110. 110. More importantly, this native “clear” button often cannot be accessed via the TAB keystroke, so it is inaccessible for many Assistive Technology users.
  111. 111. So, if you want to use a robust and accessible “clear” button, it is better to use a separate <button> element.
  112. 112. Using CSS, you can make the clear button look like it sits inside the <input> element.
  113. 113. Diagram showing three different elements - the input, the clear and the submit button Search towns in Australia Search towns in Australia
  114. 114. Then make sure to set the type to "text" rather than "search".
  115. 115. <label for="search">Search towns in Australia</label> <input id="search" type="text" aria-describedby="instructions" aria-owns="results" aria-expanded="false" >
  116. 116. ARIA-DESCRIBEDBY attribute
  117. 117. The aria-describedby attribute allows us to describe the purpose of the current element. It points the current element to a new element with a matching ID value.
  118. 118. <label for="search">Search towns in Australia</label> <input id="search" type="text" aria-describedby="instructions" aria-owns="results" aria-expanded="false" > <div id="instructions" aria-live="assertive" style="display: none;"> ... </div>
  119. 119. This allows us to provide basic instructions on the use of the widget for assistive technologies.
  120. 120. <div id="instructions" aria-live="assertive" style="display: none;"> When autocomplete options are available, use up and down arrows to review and enter to select. </div>
  121. 121. ARIA-OWNS attribute
  122. 122. The aria-owns attribute allows us to define “a parent/child contextual relationship to assistive technologies that is otherwise impossible to infer from the DOM”.
  123. 123. In other words, we can define the <input> element as the parent, and the <ul> element as the child element.
  124. 124. <label for="search">Search towns in Australia</label> <input id="search" type="text" aria-describedby="instructions" aria-owns="results" aria-expanded="false" > <ul id="results"> ... </ul>
  125. 125. ARIA-EXPANDED attribute
  126. 126. The aria-expanded attribute allows us to inform assistive technologies when the autocomplete dropdown is present. It is initially set to "false".
  127. 127. <label for="search">Search towns in Australia</label> <input id="search" type="text" aria-describedby="instructions" aria-owns="results" aria-expanded="false" >
  128. 128. This value needs to dynamically change to "true" as soon as the autocomplete suggestions are present.
  129. 129. <label for="search">Search towns in Australia</label> <input id="search" type="text" aria-describedby="instructions" aria-owns="results" aria-expanded="true" >
  130. 130. Buttons
  131. 131. Directly after the input, we need two <button> elements.
  132. 132. The first <button> should be a type of "button" and allow users to clear the input.
  133. 133. <button type="button" aria-label="Clear"></button> <button type="submit" aria-label="Search"></button>
  134. 134. The second <button> should be a type of "submit" and allow users to submit the form.
  135. 135. <button type="button" aria-label="Clear"></button> <button type="submit" aria-label="Search"></button>
  136. 136. You may want to use icons instead of text for one or both of the buttons. In this case we are using “clear” and “search” icons.
  137. 137. Search towns in Australia Diagram showing clear and search icons
  138. 138. However, if you user icons instead of text, you will need to provide additional context for Assistive Technologies.
  139. 139. In this case, we can use aria- label attributes to provide hidden labels for both buttons.
  140. 140. <button type="button" aria-label="Clear"></button> <button type="submit" aria-label="Search"></button>
  141. 141. Unordered list
  142. 142. After the two button elements, we need to add the <ul> element which will be used to display the autocomplete suggestions.
  143. 143. <ul id="results" role="listbox" tabindex="-1" style="display: none;" > <li role="option" aria-selected="false">apple</li> <li role="option" aria-selected="false">banana</li> <li role="option" aria-selected="false">pear</li> </ul>
  144. 144. As mentioned before, the ID attribute’s value of "results" allows us to determine that this element is “owned” by the parent <input> element.
  145. 145. <ul id="results" role="listbox" tabindex="-1" style="display: none;" > <li role="option" aria-selected="false">apple</li> <li role="option" aria-selected="false">banana</li> <li role="option" aria-selected="false">pear</li> </ul>
  146. 146. The role attribute can be set with a value of "listbox", which informs assistive technologies that the element is a widget that allows the user to select one or more items from a list of choices.
  147. 147. <ul id="results" role="listbox" tabindex="-1" style="display: none;" > <li role="option" aria-selected="false">apple</li> <li role="option" aria-selected="false">banana</li> <li role="option" aria-selected="false">pear</li> </ul>
  148. 148. To make sure the element cannot be brought into focus before it is triggered, we can set the tabindex attribute to "-1".
  149. 149. <ul id="results" role="listbox" tabindex="-1" style="display: none;" > <li role="option" aria-selected="false">apple</li> <li role="option" aria-selected="false">banana</li> <li role="option" aria-selected="false">pear</li> </ul>
  150. 150. This value needs to dynamically change to "0" as soon as the autocomplete suggestions are present.
  151. 151. <ul id="results" role="listbox" tabindex="0" style="display: block;" > <li role="option" aria-selected="false">apple</li> <li role="option" aria-selected="false">banana</li> <li role="option" aria-selected="false">pear</li> </ul>
  152. 152. To make sure the element is initially hidden we can set the style attribute to "display:none".
  153. 153. <ul id="results" role="listbox" tabindex="-1" style="display: none;" > <li role="option" aria-selected="false">apple</li> <li role="option" aria-selected="false">banana</li> <li role="option" aria-selected="false">pear</li> </ul>
  154. 154. This value needs to dynamically change to something like "display:block" as soon as the autocomplete options are triggered.
  155. 155. <ul id="results" role="listbox" tabindex="0" style="display: block;" > <li role="option" aria-selected="false">apple</li> <li role="option" aria-selected="false">banana</li> <li role="option" aria-selected="false">pear</li> </ul>
  156. 156. List items
  157. 157. Each of the <li> elements can be given a role attribute with a value of "option" with informs assistive technologies that they are selectable items in a select list.
  158. 158. <ul id="results" role="listbox" tabindex="-1" style="display: none;" > <li role="option" aria-selected="false">apple</li> <li role="option" aria-selected="false">banana</li> <li role="option" aria-selected="false">pear</li> </ul>
  159. 159. Each of the <li> elements needs to have an aria-selected attribute initially set to "false".
  160. 160. <ul id="results" role="listbox" tabindex="-1" style="display: none;" > <li role="option" aria-selected="false">apple</li> <li role="option" aria-selected="false">banana</li> <li role="option" aria-selected="false">pear</li> </ul>
  161. 161. This value needs to dynamically change to "true" if the individual option is selected.
  162. 162. <ul id="results" role="listbox" tabindex="-1" style="display: none;" > <li role="option" aria-selected="true">apple</li> <li role="option" aria-selected="false">banana</li> <li role="option" aria-selected="false">pear</li> </ul>
  163. 163. The hidden DIV
  164. 164. After the <ul> element, we have the <div> element, which has the instructions for assistive technologies.
  165. 165. <div id="instructions" class="off-left" aria-live="assertive" > When autocomplete options are available, use up and down arrows to review and enter to select. </div>
  166. 166. As mentioned before, the ID value allows us to point the <input> element to this <div> element via the aria-describedby attribute.
  167. 167. <div id="instructions" class="off-left" aria-live="assertive" > When autocomplete options are available, use up and down arrows to review and enter to select. </div>
  168. 168. The <div> element needs to be visually hidden, but still available to screen readers.
  169. 169. This can be achieved by setting it “off-left” using CSS. So, we can give it a pretend “off-left” class here.
  170. 170. <div id="instructions" class="off-left" aria-live="assertive" > When autocomplete options are available, use up and down arrows to review and enter to select. </div>
  171. 171. The aria-live attribute is set to "assertive". This informs assistive technologies as soon as anything inside this element is dynamically changed.
  172. 172. <div id="instructions" class="off-left" aria-live="assertive" > When autocomplete options are available, use up and down arrows to review and enter to select. </div>
  173. 173. We need this because the instructions will dynamically change as soon as the autocomplete options are triggered.
  174. 174. <div id="instructions" class="off-left" aria-live="assertive" > When autocomplete results are available use up and down arrows to review and enter to select. </div>
  175. 175. <div id="instructions" class="off-left" aria-live="assertive" > 6 options available. Use up and down arrows to review and enter to select. </div>
  176. 176. The instructions should also immediately change as users type if the number of suggestions changes.
  177. 177. <div id="instructions" class="off-left" aria-live="assertive" > 3 options available. Use up and down arrows to review and enter to select. </div>
  178. 178. The ideal method?
  179. 179. As mentioned before, this is just one method that could be used.
  180. 180. Before deciding, make sure you check out different methods and test them - with real users, and across different assistive technologies.
  181. 181. Good examples
  182. 182. One of my favourite accessible autocomplete search widgets is the haltersweb version: https://haltersweb.github.io/Accessibility/ autocomplete.html
  183. 183. However, there are a wide range of different solutions available, such as: http://www.visionaustralia.org/digital-access-autocomplete https://a11y.nicolas-hoffmann.net/autocomplete-list/ https://alphagov.github.io/accessible-autocomplete/examples/ http://oaa-accessibility.org/examplep/combobox2/
  184. 184. Russ Weakley Max Design Site: maxdesign.com.au Twitter: twitter.com/russmaxdesign Slideshare: slideshare.net/maxdesign Linkedin: linkedin.com/in/russweakley

×