Our extension is relying on the wizard dialog. During accessibility testing it was discovered that wizard step buttons are being reported as links by the screen reader (NVDA, JAWS). Claimed expected behavior by the tester is that they should be announced as buttons.
I discussed this issue with accessibility SMEs and they said it is perfectly fine to keep them as links. They did mention that they would probably design the UX differently from the start, but given that we already have it this way, links are fine. They did suggest to add few additional ARIA attributes to the link elements:
- `aria-current="step"` if the link is for the currently active step. This literally just announces "current step" at the end, when you focus on a link
- `aria-disabled="true"` makes it say "**unavailable**; link; *<step number>*" when in NVDA "browse" mode and move to the grayed-out link.
So this change implements the said improvements.
During accessibility testing it was discovered that tree view in our wizard reads "Tree Node tree view" instead of the proper label that is specified. It turned out to be the problem with the tree component, where `ariaLabel` was hardcoded to "Tree Node", instead of the one provided in the options.
This change addresses the problem by passing through `ariaLabel` from the options object to the underlying tree control. I also removed the default `Tree Node` hardcoded label, as it didn't make much sense. This does mean that all tree-views that do not explicitly specify their aria-label will now get an empty label. I think this is better than having unrelated, unlocalized `Tree Node`.
I'm also worried about changes to the `ariaLabel` property after the component was initialized. I updated the code to propagate the value to the underlying tree view in the `setProperties` override of the tree component and hope that it will take care of it.
During accessibility testing, it was discovered that screen reader does not announce what checkboxes in the tree view represent. It was merely announcing "checkbox unchecked", so it was not clear without visuals which checkbox the focus is on.
This change sets an `aria-label` of the checkbox elements to match the label of the owning tree node. This way the announcement becomes "My Node; checkbox; unchecked". This is fine as a quick solution to the problem, but in the future we may want to consider adding additional checkbox label property to the nodes exposed by the tree provider, so that each checkbox can announce additional information, if needed.
* Use built-in SQL ExecuteProvider by default if no other provider exists.
* Gracefully handle case where standardKernels are not defined for a provider.
* Standardize on just using arrays for various provider registration details.
