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.
* format doc
* correct class name
* set content
* remove mssql commands
* merge classes
* code refactoring and bug fixing
* remove unnecessary class
* handle promise
Co-authored-by: Alan Ren <alanren@microsoft.com>
* respect include header option
* use correct option for copying
* check for setting when copying
* add dependency injection
* use instantiation service
Co-authored-by: chgagnon <chgagnon@microsoft.com>
Separate the Views load from the initialization. This way we can load previously created views, and only add the new views data to the document when needed. For now, this happens only when a view is created.
