Add Accessibility/ARIA compliance to all components

[icfantv]

We need to review all the components for ARIA accessibility compliance and implement as appropriate per the ARIA spec.

Things we need to consider and evaluate:

• Keyboard Navigation for Widgets
• Keyboard Focus
• ARIA States and Properties
• Open Ajax Accessibility examples

Supported Components:

• Accordion (docs)
• Alert (docs, as modal)
• Buttons (docs)
• Carousel (docs, example)
• Collapse (docs)
• Datepicker (docs)
• Dropdown (docs)
• Modal (docs)
• Pagination ([docs])
• Popover (docs)
• Progressbar (docs)
• Rating ([docs])
• Tabs (docs)
• Timepicker (docs)
• Tooltip (docs)
• Typeahead (docs)

[icfantv]

There's a good discussion and links in #3526.

[vcarreno96]

Is it possible to trace the closed sub issue for #3474 to a specific commit/release? I'm currently on version 0.12.1 of ui-bootstrap and need this particular accessibility fix. I would like to avoid going to a minor release if possible or else I would need a change log with breaking api changes. Your help is much appreciated!

[pkozlowski-opensource]

@vcarreno96 you can find all the details is https://github.com/angular-ui/bootstrap/blob/master/CHANGELOG.md

[NickHeiner]

I'm having a bit of a hard time figuring out how much ARIA work was actually done. None of the checkboxes in the original issue are checked. Some of the linked issues have landed as PRs, whereas others appear to have been closed as duplicates of this one.

The reason I ask is that I'm working with a project on version 0.14.3, and I'm trying to determine if upgrading to the latest version will yield accessibility improvements to the modal.

[icfantv]

@NickHeiner, IIRC, we've not done much and the release we targeted for ARIA support got hijacked and we never circled back. It needs to be done so if you feel like submitting some quality PRs, please go ahead.

[NickHeiner]

Here's a PR! You can decide if it's quality 😸.

#6166

[jcwarfield]

Typeahead with custom HTML popup template specified - screen readers are not picking up the results displayed in the popup template. Seems the correct 'aria' tags are being generated but reader is silent, even when an item is 'active'. Any suggestions?

[NickHeiner]

@jcwarfield can you try my PR (#6203) and tell me if that fixes your problem?

[jcwarfield]

Hi Nick, thanks for the quick response. I think your PR is a good addition, but does not fix the issue I'm having. Our uib-typeahead is using a custom popup template property (typeahead-popup-template-url), that points to an embedded template in the same html file (script type="text/ng-template" id="sectionList.html"). I think the problem may be that the custom template is being inserted into the DOM after the page is rendered, but before typing occurs, so the screen reader does not pick up the results in the popup. Is the template being injected after the page is rendered and a user begins typing?

[NickHeiner]

Ah yes, then my PR is not going to help you. That's a separate issue. And yes, I have seen it make a difference whether a DOM attribute exists when the elements are put into the DOM, as opposed to being added later.

[andypotts]

@jcwarfield, did you have any luck resolving the typeahead accessibility (screenreader) issue?

[meghanking]

Is there any update for these changes?

[jcwarfield]

Actually it's been over a year since working on that project, so it was still unresolved at the time I left.

[jrencz]

I'd like to mention that Modal component may not only take modal role. It may also be alert or alertdialog.

I considered implementing it over angular-ui-bootstrap in my application and I came into a conclusion that if backdrop is static (which in my case also means there's no "X" in the corner, but it's my app specific) then it's alertdialog (in my case it's always some way to interact).

I think there should be an optional param in $uibModal.open which says what kind of role should be applied. Now I would have to implement that with raw DOM api