New: Add support for Tooltip API and Navigation Button API (fix #128)

[swashbuck]

Fix #128

New

• Add navigation button label and tooltip support

Testing

• See course.json config in the updated example.json

[oliverfoster]

Could you nest the config one deeper? course.json:_devtools._navButton.ariaLabel rather than course.json:_devtools.ariaLabel.
As it's a subpart of devtools.

_navButton / _nav, something like that?

adapt-devtools/schema/course.schema.json

Lines 11 to 31 in becbff3

	"_globals": {
	"type": "object",
	"default": {},
	"properties": {
	"_extensions": {
	"type": "object",
	"default": {},
	"properties": {
	"_devtools": {
	"type": "object",
	"title": "Dev Tools",
	"default": {},
	"properties": {
	"ariaLabel": {
	"type": "string",
	"title": "Navigation button aria label",
	"default": "Developer tools",
	"_adapt": {
	"translatable": true
	}
	},

[kirsty-hames]

Works as expected thanks @swashbuck 👍

[kirsty-hames]

Could you nest the config one deeper? course.json:_devtools._navButton.ariaLabel rather than course.json:_devtools.ariaLabel. As it's a subpart of devtools.

_navButton / _nav, something like that?

adapt-devtools/schema/course.schema.json

Lines 11 to 31 in becbff3

	"_globals": {
	"type": "object",
	"default": {},
	"properties": {
	"_extensions": {
	"type": "object",
	"default": {},
	"properties": {
	"_devtools": {
	"type": "object",
	"title": "Dev Tools",
	"default": {},
	"properties": {
	"ariaLabel": {
	"type": "string",
	"title": "Navigation button aria label",
	"default": "Developer tools",
	"_adapt": {
	"translatable": true
	}
	},

Good point. Annoyingly we haven't defined a consistent approach to how we've defined nav button aria labels (when comparing against pageLevelProgress, Visua11y and roleBasedContent each has a different approach). Instead would replacing _devtools.ariaLabel with _devtools.navAriaLabel be efficient to keep all nav button properties at the same level?

[oliverfoster]

You'd have to do _showLabel as well. It's probably easier just to nest them and keep the names as they are in NavigationButton API as these are just passthrough properties for a self-contained bit of behaviour.

[swashbuck]

Thanks, both. I've nested the properties under _navButton in 2d63b1b. Kept _navTooltip as it was. Let me know if this works and I can update ToC.

[oliverfoster]

Remember that we have migration scripts now if you want to harmonise these things.

[kirsty-hames]

Thanks @swashbuck. Having reviewed this again, I don't believe ariaLabel is actually used here. The accessible name is instead provided by the tooltip text via aria-describedby:

This aligns with how it's handled in PLP:

It's worth noting that the core back and drawer buttons do use aria-label. Should ariaLabel be used, or removed to stay consistent with PLP?

[swashbuck]

Having reviewed this again, I don't believe ariaLabel is actually used here. The accessible name is instead provided by the tooltip text via aria-describedby

@kirsty-hames Good spot. I think there's definitely an issue here. I'm not hearing the screenreader announce anything for the Dev Tools button.

I would think that it would work like this:

1. If tooltips are enabled globally and on the button, the name is provided by the tooltip text via aria-describedby.
2. If tooltips are disabled globally or disabled on the button, the name is provided instead by the ariaLabel

@oliverfoster Do you recall if this is how it should work?

[oliverfoster]

No, I don't, I don't recall this conflict.
Please use other similar plugins as a reference. Fixes may need to happen on those also.

[swashbuck]

I'm not hearing the screenreader announce anything for the Dev Tools button.

This should be fixed now. The aria-label attribute now uses the _devtools._navButton.ariaLabel value.

As far as I can tell, the aria-describedby attributes are not being read on any of these buttons (PLP, Home Button, etc) due to a separate bug in the tooltip API.