Category: screenreader

Categories
aria forms screenreader

Datalist over ARIA combobox

Summary: This article suggests that the custom select dropdown is overused. The ARIA combobox pattern to create one is very complex and has inconsistent support. Instead, the native HTML datalist element should be leveraged to create a similar UI control, and its support is pretty good. Code snippets, keyboard testing results, and basic screen reader testing results are provided.

Customizing a Select is not ideal

Due to extreme complexity, and usually spotty accessibility support, customizing an HTML select element is not recommended. There have been many noble attempts, but at the end of the day, it’s just not worth the many, many hours that web designers and developers and testers dedicate to this. And often it’s not needed; much of its demand is due to ill-perceived competition and designer narcissism. It’s always better to use native HTML.

Autosuggest adds even more complexity to the problem of customizing a native HTML select. The ARIA combobox pattern is appropriate for implementing autosuggest, but it’s inconsistent between ARIA versions, very intricate to implement, and there are many nuances and different levels of support by browsers and screen readers.

Enter datalist

We can address this issue by simply implementing the native datalist HTML element in conjunction with an input element. Doing so (and not customizing via ARIA) eliminates a huge amount of code complexity, code weight, design inconsistency, testing time, etc. The result is a control which functions like an autosuggest dropdown and text can also be entered into the input field.

The datalist element is defined in the spec as:

a set of option elements that represent predefined options for other controls. In the rendering, the datalist element represents nothing and it, along with its children, should be hidden.

Demo of the datalist element. Control appears like a select and has options displayed below.
Example of the datalist element in Chrome.

Datalist support

Datalist has been around for years now, but only recently has browser support and its accessibility been good enough to consider using. Check out datalist on CanIUse.com for info on browser support (that’s a lot of green!)

In a recent Tweet from Paul Adam, he states “HTML <datalist> Tag seems accessible enough now to recommend over an ARIA combobox”. Support could be improved (see testing results below), but all things considered, I agree. His tweet includes a screenshot of VoiceOver using the element, with Safari it appears.

Simple is good

The beauty of the datalist element is simplicity. Straight forward, semantic, and simple HTML – and no JavaScript needed! Here is an example – a label, an input, and the programmatically associated datalist element which contains the options.

<label for="browser">Choose your browser from the list:</label>
<input list="browsers" name="browser" id="browser">
<datalist id="browsers">
  <option value="Edge">
  <option value="Firefox">
  <option value="Chrome">
  <option value="Opera">
  <option value="Safari">
</datalist>

Testing datalist

I’ve done some keyboard and screen reader testing using this datalist test page on CodePen. Support isn’t perfect, but overall it’s pretty good!

Keyboard testing results

After testing with Chrome, Firefox, and Safari, it seems Chrome on both Mac and Windows provides the best keyboard support.

  • Chrome (Mac and Windows):
    • Caret icon appears on focus
    • Option list appears when typing (option list also appears on focus)
    • Option list appears via spacebar
    • Option list appears via down arrow
    • Arrow + Enter to select an option
    • Escape closes the option list
  • Firefox (Mac and Windows):
    • Caret icon NOT displayed on focus nor by default
    • Option list appears when typing
    • Option list DOESN’T appear via spacebar
    • Option list appears via down arrow
    • Arrow + Enter to select an option
    • Escape closes the option list
  • Safari:
    • Caret icon displayed by default
    • Option list appears when typing
    • Option list DOESN’T appear via spacebar (note that with VoiceOver on, it appears with VO + spacebar)
    • Option list DOESN’T appear via down arrow
    • Arrow + Enter to select an option
    • Escape DOESN’T close the option list

Screen reader testing results

Screen reader usability seems adequate but could use improvement. Here are a few details. No mobile testing was done.

  • NVDA + Firefox
    • Upon focus, outputs “Choose your browser: combo box has auto complete editable blank”
    • Upon opening the option list with the down arrow, outputs “blank” then after down arrow again, “list, Edge 1 of 5”
  • NVDA + Chrome
    • Upon focus, outputs “Choose your browser: combo box has auto complete editable blank”
    • Upon opening the option list with the down arrow, outputs “Autofill  list  expanded, Edge  1 of 5″
  • VoiceOver + Safari
    • Upon focus, outputs “Choose your browser:, list box pop up, edit text”
    • Upon opening the option list, outputs “Suggestions list visible”
  • JAWS + Chrome
    • Upon focus, outputs “Choose your browser: edit combo. To set the value use the Arrow keys or type the value.”
    • Upon opening the option list, outputs “Autofill. List box expanded. Edge, 1 of 5. To move to an item press the Arrow keys.”
Screenshot of the datalist test page. The option list is open and Firefox is selected. NVDA speech viewer displayed.
Navigating the datalist example on the CodePen test page using NVDA on Firefox.

Wrapping Up

Browser support for the HTML datalist element is getting much better, especially on Chrome. Although support isn’t perfect—and nothing is—it’s still pretty good. Is it time to start using datalist instead of heavily customizing similar controls with ARIA? I believe it is, especially considering the vast amount of product development time it would save compared to customization.

Further reading

Categories
screenreader stats survey

Screen Reader User Survey 7 Results from WebAIM

In December 2017, results of Screen Reader User Survey #7 by WebAIM were released. The survey was conducted in October and had 1,792 valid responses. The survey had less respondents than the previous survey, but had better world-wide representation.

Highlights:

  • Primary screen reader usage: JAWS 46.6%; NVDA 31.9%; VoiceOver 11.7%.
  • CAPTCHA remains the most problematic item.
  • The second most problematic item is now “Screens or parts of screens that change unexpectedly”. This is surely due to complex designs and SPAs/JS frameworks.
  • Web accessibility basics (keyboard access, alt text, forms, headings, data tables) are still in top 10 of most problematic.
  • When asked if more accessible web sites or better assistive technology would have a bigger impact on accessibility, 85.3% responded more accessible web sites.
  • Sadly, frequent use of landmarks and regions dropped to 30.5%. WebAIM states that this may be “due to infrequent or improper usage of landmarks/regions in pages”.
  • 33.3% reported using Braille output with a screen reader.
  • 41.4% reported using an external keyboard with a mobile device and screen reader.

I highly recommend you also read WebAIM’s summary of Screen Reader User Survey.

More:

WebAIM web accessibility in mind

Categories
"assistive technology" screenreader survey webaim

Assistive Technology Surveys

Digital accessibility experts are often asked about the usage of screen readers and assistive technologies. For example, one will often ask “What’s the most popular screen reader?” This is difficult (if not impossible) to determine technically, but also has privacy implications and other problems.

The following two surveys provide great data and are provided by very reputable organizations. Keep in mind though that the respondents were not controlled and the sample sizes are relatively low.

Are you aware of any other recent surveys?

Related:

A person using a laptop computer wearing headphones and touching a braille output device.
A person using assistive technology.
Categories
apple design ipad keyboard screenreader

Apple’s Inaccessibility

Apple has traditionally been a great advocate and model for accessibility and technology. Unfortunately this hasn’t been the case lately. One could even argue that default settings and recent designs are even counterproductive to accessibility progress. This includes VoiceOver, keyboard access, and design decisions.

Bug Infested

To begin, let’s reference a recent article by Marco Zehe where he explains major VoiceOver bugs in OS X 10.10 (Yosemite) and iOS 8. The two major examples he cites are:

  • When VoiceOver is running on the iPhone, using the Back button (or Scrub gesture to return to the previous page) will freeze VoiceOver.
  • When VoiceOver is running on the iPad, using Safari and the use of WebView components trigger app crashes and OS restarts.

In addition to bugs, I’ve noticed the following blatant accessibility problems pop up in Apple’s products. Each of these alone may not be a showstopper but collectively it shows a pattern of a company that doesn’t care, or pay much attention any longer; a company that’s losing its edge.

VoiceOver Hints

By default, VoiceOver places a large delay when announcing “hints”; this creates a huge lag for the reading of text defined by the aria-describedby attribute. And we all know that the support of aria-describedby is becoming more and more prevalent and essential in today’s world of modern web development. The delay is so long that it creates confusion; developers and testers very often think something is broken.

To “fix” the setting, you must find the deeply buried option and modify the delay time; in System Preferences, go to Accessibility / VoiceOver / VoiceOver Utility / Verbosity / Announcements (in OSX 10.9, it’s the the last setting).

Keyboard Access

A great example of Apple’s inaccessibility is the setting for keyboard focus; by default it doesn’t allow for typical keyboard navigation! A user cannot use the tab key to access all controls in an interface. In order to fix, one must again, search for the appropriate settings and modify. Again, this can be confusing and frustrating for developers and testers, let alone regular users.

To fix, the first step is to go to System Preferences / Keyboard / Shortcuts, and in the last section “Full Keyboard Access”, ensure the radio options “All Controls” is selected.

Let’s refer to the follow articles for more details on how to resolve which includes specific browser settings:

Design Problems

There are two major design issues by Apple recently which hinders accessibility: animations and parallax effects, and flat design.

There are many vestibular-related issues in Apple’s design, most notably during the release of iOS7. The issue continues to iOS8 although iOS settings are now available to help resolve the issue. To reduce parallax-type effects in iOS, go to Settings / General / Accessibility / Reduce Motion.

Also, iOS flat design (and the trend in general) is bad for usability and accessibility. Mostly because flat design creates ambiguity between elements; as the Nielsen Norman Group report states, “flat design hides calls to action“. And by implementing flat design, Apple indirectly encouraged others to do the same.

In addition to Nielsen Norman Group’s finding, another usability expert Steve Krug agrees that flat design is a detrimental practice. Here’s a quote from his book which was tweeted last May:

Hope and Warning

Let’s hope Apple returns to the practice of releasing quality products: everything just works and accessibility is continually improving. And fair warning, after the mobile wars a few years ago, Google tops Apple in mobile operating systems; will accessibility be next?

Related Reading

Categories
screenreader

Detecting Screen Readers – No

There has been much discussion about the idea of detecting a screen reader from a website and optimizing the code. In the W3C editor’s draft IndieUI 1.0: User Context, screen reader detection is proposed. This scares me and many others in the web accessibility community.

In the recent publishing of the WebAIM screen reader survey, one of the questions is “How comfortable would you be with allowing web sites to detect whether you are using a screen reader?”. Surprisingly 54% of respondents replied “Very comfortable”. This sure sparked some discussion on Twitter and on blogs.

For the most part, detecting a screen reader has been ill-received from the accessibility community. I am also strongly opposed to this idea.

The reasoning boils down to two issues: development and privacy. And it’s bad for both. Here are some reasons why it’d be bad for development:

  • Text-only websites didn’t work before and you know devs will do this if a mechanism is provided.
  • Screen reader detection is eerily similar to the browser-sniffing technique which has proven to be a poor practice.
  • Maintaining separate channels of code is a nightmare; developers overloaded already with supporting multiple browsers, devices, etc (via RWD). And if done, it will many times become outdated if not entirely forgotten about.
  • Why screen reader detection? If you follow that logic, then detection should be provided for screen magnifiers, braille output devices, onscreen keyboards, voice-recognition, etc. That’s just a bad idea.

Let’s hope screen reader detection is removed from the W3C draft of IndieUI 1.0: User Context.

PS: Interestingly, @LFLegal recently announced that Safeway is (finally) removing a text-only version of its website in the blog Separate is Not Equal: Good News for Grocery Delivery.

Further reading:

Updated August 2023