Accessibility support

[gorner]

I'm part of a team that has been looking at using Shepherd (and ember-shepherd) within one of our externally-facing Ember sites, however we've noticed that the accessibility support is fairly minimal - there are no ARIA attributes on any Shepherd elements and the semantic markup could be improved (no nav tag around the navigation buttons, for example).

I know there was an issue #26 raised along these lines but it was closed without explanation late last year.

I realize that this is a period of transition in terms of the stewardship of Shepherd but I was wondering if any efforts were being planned in this regard.

[RobbieTheWagner]

Hi @gorner, thanks for bringing this to our attention. We did not have any specific plans, but a11y is a good goal for all projects these days. If you have a set of things you'd like us to look at and/or wanted to help implement some of those things, we'd be glad to take a look 😃

[gorner]

Fair enough, I'm planning to take a look in the next few days/weeks to better articulate what we'd be looking for.

[RobbieTheWagner]

@gorner any updates on the sort of accessibility things you are looking for?

@BrianSipple @chuckcarpenter do you guys have any ideas?

[gorner]

@rwwagner90 Thanks for the reminder 🙂

We've had a few suggestions from our a11y SMEs recently – to be clear, our evaluation is still ongoing and my time to play around with this myself has been limited. A brief summary of what where we've gotten thus far:

• We should be able to set an ARIA role on the main parent element of the step content (it's a bit unclear to us if this should be .shepherd or .shepherd-content). Perhaps this attribute should be set to a appropriate default with ability to override. For modal scenarios, "dialog" or "alertdialog" might make sense. In our case we're planning to use the non-modal option which may imply "alert". I note that the similar intro.js library uses "dialog".
  • For the non-alert, non-modal case, we may need to be able to separately set an aria-live value.
• Parent element should have an aria-describedby attribute (with the id of the .shepherd-text element); and if applicable, an aria-labelledby attribute (with the id of the .shepherd-title element)
• When used as a modal, tabindex="0" may need to be set on parent element
• Buttons (that perform actions without linking elsewhere) should be coded as button elements, not as a tags. One of our SMEs also suggested these should be put into the footer directly without an intermediary ul.

Other points that are less clear-cut:

• The main content div might make sense as a <section> tag since it is a thematic grouping of content. However in this case it should have a heading in which case the title would need to be mandatory (or perhaps it should be setup such that it's only a section if the title is present, and leave as a div otherwise).
• Because of how Shepherd structures its DOM, we may need some ability to provide screenreader-only content and/or action/link, to direct users with low/no sight to the actual feature. In theory the aria-flowto attribute would help handle this but browser support seems to be very limited.
• One of our SMEs suggested that h2 may be more appropriate for the heading than h3, but I realize that this may be a matter of interpretation.
• Re my earlier comments about whether the buttons should be contained within a nav tag, we are still examining whether this is needed. The role="navigation" attribute might also make sense for this.

[gorner]

One other a11y item - the option to close the tour when clicking outside the tour area or pressing the Esc key (as suggested in #141) would also be helpful for us, though as noted in that issue, those parts at least are feasible to implement on a per-app basis.

[RobbieTheWagner]

@BrianSipple do we get some of this for free with the conversion to tippy?

[BrianSipple]

@rwwagner90 Tippy has a minor perk where it adds tabindex=0 to the target element, but that's it. I think the list @gorner provided is worth going through to see what we can address. I'm open as to whether or not we want to target that as part of the 2.0 release, or 2.x or 3.0.

[RobbieTheWagner]

@BrianSipple I think we can do it in 2.x or 3.0. It should be all additional stuff, hopefully nothing breaking.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.