Good Morning!

Gerard K. Cohen

Lead Accessibility Strategist, Wells Fargo Digital Solutions for Business (DS4B)

Slides: http://bit.ly/2OxNPro
@gerardkcohen

Custom Select

Problems with Custom Select

Nobody ever does all that sh*t!

It's hard af

Reasons for Custom Select

Truncated list items on mobile.
Multiple selections.
Better Grouping options.

So, considering it is such a big no-no, why did I do this? I had some problems that I needed to solve.

The biggest being that FRAGMENT, on iOS long option values would get truncated. We have to be able to support user generated content and really long account numbers. Sometimes, the only difference in an account numbers is the last couple of digits. If those get cut off then there is no way to know what is what. In general, the experience on mobile devices is not that great.

Some additional problems, is FRAGMENT supporting multi-select options. The native multi-select takes up too much space, is hard to operate with keyboards, and actually doesnt even announce as being able to accept multiple selections.

Lastly, we need to provide better formatting for grouped options. Of course, being able to provide a styled select was nice too.

Styling

ARIA Authoring Practice: Listbox

Not fully supported.

Because the purpose of this guide is to illustrate appropriate use of ARIA 1.1 as defined in the ARIA specification, the design patterns, reference examples, and sample code intentionally do not describe and implement coding techniques for working around problems caused by gaps in support for ARIA 1.1 in browsers and assistive technologies.

- W3C ARIA 1.1 Browser and AT Support

Except in cases where the ARIA Working Group and other contributors have overlooked an error, examples in this guide that do not function well in a particular browser or with a specific assistive technology are demonstrating browser or assistive technology bugs. Browser and assistive technology developers can thus utilize code in this guide to help assess the quality of their support for ARIA 1.1.

- W3C ARIA 1.1 Browser and AT Support

Currently, this guide does not indicate which examples are compatible with mobile browsers or touch interfaces. While some of the examples include specific features that enhance mobile and touch support, some ARIA features are not supported in any mobile browser. In addition, there is not yet a standardized approach for providing touch interactions that work across mobile browsers.

- W3C ARIA 1.1 Browser and AT Support

ARIA Authoring Practice: Listbox

Not fully supported.
Not a form element.
Optgroup?

The parts:

HTML, CSS, Vanilla JavaScript.
Native Select (progressive enhancement).
Span.
Unordered list.
ARIA.

First let's talk about the major players here.

I am going to be demonstrating code is plain old web technologies: FRAGMENT HTML, CSS, and vanilla JS. I wanted to be able to demonstrate everything without forcing you all to be human JS compilers, but honestly the real start is the HTML anyway.

FRAGMENT, I'll be starting with a native select because I like progressive enhancement. I think that is still a worthy cause. I moved to the suburbs where internet connectivity is very spotty, my browsing experience on my iphone is pretty crappy. It's also pretty bad when I take the train into the city. I don't want to sound like I am yelling "get off my lawn" but I really don't have patience these days for a brochureware site to download and render entirely in JS.

FRAGMENT elements being used are a simple span for the trigger and an unordered list for the options.

and of course, lots of FRAGMENT ARIA

Inspiration

ARIA 1.1 Pattern.
Native Select on various platforms.

Keyboard Interaction: Select Trigger

SPACE, UP, DOWN to display the list.
Focus moves to unordered list.

Keyboard Interaction: Option List

UP/ DOWN to navigate the items, but they do not cycle. Navigating does not make a selection.
HOME moves to the first item in the list.
END moves to the last item in the list.
Type-ahead (printable characters).
SPACE will select item, close list, and focus on trigger.
ESC will close the list and focus on trigger without making a selection.
Safari: TAB is trapped.

FRAGMENT FIRST we'll talk about selection in a second.

FRAGMENT

FRAGMENT The ARIA pattern has a notice about whether or not selection should follow focus, that is, should the value of selection be updated as your navigating along the options. This does happen on Windows, so if you want stick with this you can. I chose to make selection a specific interaction, requiring a SPACE keypress for selection.

FRAGMENT FIRST. With Windows, ESC closes the dropdown and the last item you had focused, is your selection. This just doesnt feel right, there is no way to back out of a selection. If you feel it is important to maintain this, go for it.

FRAGMENT lastly, I wanted to point out that in safari, when a list is open TAB is essentially trapped. On Windows, TAB will just close the list and return focus back to the dropdown trigger.

Mouse/ Touch Interaction

Tap/ click to open.
Tab/ click to select.
AT: Swipe to navigate.

Discoveries, Tips, and Hacks!

role="combobox" vs button

Native selects on windows announce as combobox.
combobox is recognize as a form element.
Because of combobox role, certain automated tests will complain because there is no textbox child.
aria-required not allowed on buttons.

The ARIA authoring practices show examples of using a button for the select trigger, and I can assume they did this because the role="combobox" by definition is composite widget, consisting of a text input field and list.

Despite this, I ended up choosing the role of combobox for 2 reasons.

FRAGMENT windows announces native selects as combobox. VO just announces it as pop up button.

FRAGMENT combobox is recognized as a form element. If an assistive technology user is trying to discover elements by type, inf this case form elements, then the combobox will show up. Button will not show up as a form element, and may not be obvious to look there.

FRAGMENT aria-required not allowed on buttons. This makes it less of a form element. You could get around this by just adding required information to the label.

aria-selected not announced

added ", selected" to the option aria-label.

a surprising discovery was that the aria-selected state was announced at all. When navigating the list, there was no notification that an item was selected or not. Of the three screen readers I tested, VO the best by announcing announce the number of items selected, and the actually items selected upon first announcing the list. JAWS 2018 and IE11 announces the selected item with upon first announcing the list, but its strange announcement, for example if you ad already selected DOG, it would just anonnounce LIST DOG. NVDA and FF did not announce anything at all. SO, It's possible that you are expected to remember that selection from the trigger but that just didnt seem right to me. To get around this, I just FRAGMENT added the string ", selected" to the option and that announced fine.

Interestingly, FF and JAWS 2018 on Windows 10 did start announcing the aria-selected state. Since this started happening, FF with JAWS is announcing "selected" twice, once from the state and once from the label. NVDA and FF did not have this double announcement.

Firefox not announcing combobox content

set the aria-label to the selection + field name.

On Windows 7, I had a problem where Firefox was not announcing the content of the combobox element, it just announced the role and the expanded state, but not the value. This happened in Firefox with both NVDA and JAWS, but not in IE, so I feel confident that it is an issue with FF. Except in Windows 10, it was definitely not announcing with NVDA, with either FF or Edge. So, not sure what is really going on here.

In any case, I got around this by using my favorite fix, FRAGMENT, I forced the content using aria-label on the combobox to announce the field name and the selected item.

One important thing about setting aria-labels, make sure that it matches the visual label. at least make sure that what is visible is at the start of the aria label. this is for users using VOICE technologies.

aria-describedby

EDGE did not announce aria-described information. Log a defect?
iOS and announced after a brief pause.
JAWS and IE11 announced instructions every time.

Mobile (iOS)

Important! Render list right after the trigger.
Listen for focus events on the document.
VO focus stays on combobox.
Trigger (combobox) and selected states announce twice.

Form Controls

Native select under the hood.
Submitted or serialized.
Easy validation.

Design

Overscroll: overflow: hidden on body
List positioning (selected item in middle).
Selected Check mark.

Just a few of additional interaction and visual design considerations to point out

FRAGMENT Overscroll is handled by setting overflow hidden on the body when the list is displayed. In the case that the list of items needs to scroll, this will keep your users from inadvertently scrolling past the end of the list and scrolling the rest of the page.

FRAGMENT another nice thing, which I did not implement here, is that selects will open the list so that the selected item is right in place of the label when it is collapsed, which is really nice. Imagine if you have a longer list, and the selected item is at the bottom, you probably couldnt tell if the position wasnt updated for you.

FRAGMENT If you noticed, the selected items display a check xmark to help signify a selected item. This is so we don't only use color, or background color changes, to express selection.

Demos

Code

http://bit.ly/2yVMZjw

Markup: Native Select



    Favorite Animal

Markup: Custom Select


  Favorite Animal
  Choose a favorite animal
  
    Dog
    Fish
    Horse
    Bird
    Ferret
    Not cat

Markup: Grouped Options

JS: Type-ahead

Summary

So, I know that was a lot of information but I am hoping that you got something out of it. As mentioned earlier, it may have been a little unconventional, you might even think it wasn't worth the effort, but I had an opportunity to improve the experience for our users and that made all this worth the effort.

At the end of the day, custom selects are not going away. I know sometimes its easier to say no to something than to explain it fully, but I don't think telling designers and developers not to build custom selects is doing anything but making accessibility worst. I am hoping that all you can take everything that I have shown you here, we can crowd source to make it better for everyone so that hopefully one day building custom selects won't be such a bad thing.

One last thing real quick before I go, I just want to send a shout out to my team, who helped me test a lot of this stuff. Richard Steinberg for his JAWS help and Shell Little for her NVDA help. hashtag auxSquad.

Good Morning!

Gerard K. Cohen

Custom Select

Problems with Custom Select

Problems with Custom Select

Nobody ever does all that sh*t!

Reasons for Custom Select

Styling

ARIA Authoring Practice: Listbox

ARIA Authoring Practice: Listbox

The parts:

Inspiration

Keyboard Interaction: Select Trigger

Keyboard Interaction: Option List

Mouse/ Touch Interaction

Discoveries, Tips, and Hacks!

role="combobox" vs button

aria-selected not announced

Firefox not announcing combobox content

aria-describedby

Mobile (iOS)

Form Controls

Design

Demos

Windows 10, Firefox, and NVDA

Windows 10, Firefox, and NVDA

Windows 10, Firefox, and NVDA

Code

Markup: Native Select

Markup: Custom Select

Markup: Grouped Options

JS: Type-ahead

I know what you're thinking,

Summary