jsHero
jsHero

Reputation: 180

Accessibility for dropdown component

I am implementing accessibility for dropdown component, the special feature of my dropdown is it populates values in options menu only while opening dropdown,meaning it on the fly compiles the template and attaches to the dropdown box.

Dropdown HTML: 

<div id="dropdown" ng-click="openDropdown()">
   <div id="selectedValue"  role="listbox"  tabindex="0" aria-label="{{selectedVal}}" aria-owns="dropDownMenu">{{selectedVal}}</div>
</div>

DropDown Menu template(which gets compiled and polpulated after clicking dropdown above) :

<div id="dropDownMenu">
  <li ng-click="selectItem()" role="option">item1</li>
  <li ng-click="selectItem()" role="option">item2</li>
</div>

I am facing two problems

  1. As my #dropdownMenu gets generated on click of #dropdown(dynamic template generation) jaws do not have access to #dropdownMenu when focus comes to #selectedValue so it doesn't announce the number of options etc as in case of a typical selectbox.

  2. I am giving aria-label="{{selectedVal}}" for #selectedValue so on click of arrow keys javascript takes care of updating selectedVal even though #dropdownMenu is not open ,but changed value of selectedVal is not announced by jaws 16.0 ,it only announces it only first time as user tabs into it .Noted that this works fine in jaws 14.0 .

Looking forward for some solutions....

Upvotes: 0

Views: 4043

Answers (2)

Hrvoje Golcic
Hrvoje Golcic

Reputation: 3686

You should probably wait until the element is rendered and appeared in the DOM and only then set the focus to the first submenu item by using a native function .focus(). That will do the job.

But... Make sure that if the request takes too long and the user has already left somewhere else doing something else on the page, that in this case you don't steal his focus to get him back to the dropdown menu otherwise he might be annoyed.

Also instead of tabindex=0 for interactive elements (wherever you use ng-click) I would recommend that you use the actual native elements such as <a> or <button>. That way you ensure that the elements will be focusable both by keyboard but also visually, and react to ALL keyboard keys which the users are used to use and thus expect it to react such as SPACE or ENTER without needing you to implement it manually.

Upvotes: 1

stringy
stringy

Reputation: 1353

  1. Adding aria-live=polite should fix this.
  2. Is there a reason you're not using a standard select box and populating the option elements with your dynamic content? That would remove the need to update an aria property with the current option, as screenreaders will find it themselves. Also aria-label should be the name of the selectbox (or its purpose) not its selected option. If you were using a HTML select with options you could then remove the tabindex and aria-live as well, since native form inputs have full keyboard and screenreader support by default.

Upvotes: 1

Related Questions