Feature/component description

As the title says! This will need more info as we get closer to this.

This plan captures our work in June. We will ship our preview release July 01 2021.

Our goal for this iteration is to enable internal extension authors to consume the toolkit so we can gather feedback and ideas. We're tracking the following outcomes for this iteration:

• P0 components are available via public NPM package
• Devs can reference usage guides, sample extensions, and Storybook examples
• Component theming is fully configured

Storybook

Plan Items

Below is a summary of the top-level plan items.

Components

• Badge
  • Split into Badge and Tag components (#117)
• Breadcrumb (incl. Breadcrumb Item)
• Button
• Checkbox
• Combobox
• Data Grid
  • Fix rowsData method bug (#120)
• Divider
• Dropdown
  • Convert dropdown styling to align to VS Code (#142)
• Link
• Number Field
• Panels
• Progress Bar
• Progress Ring
• Radio Group (incl. Radio)
• Tag
• Text Area
• Text Field

Theming, Styles, and Layout

• Create design token for remaining component magic values (#121)
• Unify input border styles (#95)
• Simplify design unit implementation (#115)

Accessibility

• Check that all accessibility Storybook tests are passing
• Check that VS Code accessibility standards are being met
• Run Accessibility Insights on toolkit

Infrastructure

• Add Microsoft copyright boilerplate to the top of each source code file

Testing

• Write unit tests for utility scripts

Docs

• Prevent Storybook from triggering window shortcuts while typing in input components (#96)
• Add value attribute documentation to relevant components
• Validate documentation for readability and correctness

Sample Extensions

• Hello World
• Weather
• Update samples to use latest version of toolkit

Describe the bug

The term 'foobar' has controversial historical origins (a military term used to describe horrific battle injuries, F.U.B.A.R) and much like the update from 'master' to 'main' in branch naming, this term should also be considered for an update.

To reproduce

Fragments of the term are found in:

• checkbox/README.md
• checkbox/checkbox.stories.ts
• checkbox/fixtures/createCheckbox.ts

Expected behavior

Expect neutral sample content in example code snippets

Additional context

Add any other context about the problem here.

Actual:

NVDA does not announces any information about "default progress bar" when navigating using down arrow key in browse mode.

Similar issue is observed with Jaws

Similar issue is with "Default Progress ring"

Expected:

NVDA should be announcing information about "default progress bar" when navigating using down arrow key in browse mode. It should be announcing like "loading"

GitHubTags: #A11yMAS;#A11yTCS;#A11ySev2;#SH_VscodeWebviewUiToolkit_Aug2021;#Webview UI Toolkit for Visual Studio Code;#Win32;#FTP;#DesktopApp;#WCAG1.3.1;#NVDA;#Jaws;#STP;#AINotInScope;

Environment Details:

Application Name: Vscode Webview Ui Toolkit
Windows Version: Win10
Screen Reader: NVDA(2021.1), Jaws(2021.2102.34)

Repro Steps:

1. Launch VS Code
2. Open WebView UI Toolkit: All Component extension
3. Tab to "Progress bar"
4. Start NVDA in browse mode, use down arrow to navigate to "default progress bar" and check the announcement

User Impact:

Screen Reader users will not get the proper information about the "default progress bar"

“Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”

Begin process to make toolkit available via public NPM registry.

@hawkticehurst feel free to add info here if needed

“Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”

GitHubTags: #A11yMAS;#A11yTCS;#A11ySev2;#SH_VscodeWebviewUiToolkit_Aug2021;#Webview UI Toolkit for Visual Studio Code;#Win32;#FTP;#DesktopApp;#WCAG1.4.10;#Zoom;#AINotInScope;#A11yWCAG2.1;

Environment Details:

Application Name: Vscode Webview Ui Toolkit
Windows Version: Win10

Prerequisite:

Set resolution to 1280*1024
Zoom in to 400%

Repro Steps:

1. Launch VS Code
2. Open WebView UI Toolkit: All Component extension
3. Tab to data grid and observe if all the column headers of data grids are visible properly at 400% zoom.

Actual:

The column headers of data grid are not visible properly at 400% zoom. The column headers are only visible as C.... .

Expected:

The column headers of data grid should be properly visible properly at 400% zoom.

User Impact:

Low vision users will not get the proper information about the data grids.

Describe the bug

The current min-width of some components is too large for the min-width of Webview View sidebars and will overflow past the sidebar border.

To reproduce

The easiest way to reproduce is:

• Open the weather-webview sample extensions
• Look at the text field search box

Expected behavior

The min-width of components should be smaller than the Webview View sidebar width.

Screenshots

Desktop (please complete the following information):

• OS Version: macOS 11.5.2
• Toolkit Version: v0.6.1

Describe the bug

A clear and concise description of what the bug is.

Expected behavior

It looks like the default configuration of the breadcrumb item renders a slash as a separator instead of a chevron per VS Code defaults.

Screenshots

Webview toolkit

VS Code

Desktop (please complete the following information):

• OS Version: macOS 11.3.1
• Toolkit Version: 0.5.0

Feature/component description

Right now we just have a default favicon—it would be cool to use the VS Code icon or some other related icon to make the site feel slightly more "official".

Screenshots/references

Describe the bug

The spacing of icons inside some components is not being rendered correctly when compared to its Storybook counterpart.

To reproduce

The easiest way to reproduce is:

• Open the all-components sample extension

Expected behavior

All components that render icons should look identical to their counterpart in Storybook.

Screenshots

Desktop (please complete the following information):

• OS Version: macOS 11.5.2
• Toolkit Version: v0.6.1

Describe the bug
I have codicons setup and working in the Webviews but can't seem to load them via the components

To Reproduce
Steps to reproduce the behavior:

1. Add breadcrumb component
2. See icons do not show up

Expected behavior
To have codicons show up

Screenshots

Desktop (please complete the following information):
Version: 1.56.0-insider (Universal)
Commit: 23a2409675bc1bde94f3532bc7c5826a6e99e4b6
Date: 2021-04-21T05:59:06.814Z
Electron: 12.0.4
Chrome: 89.0.4389.114
Node.js: 14.16.0
V8: 8.9.255.24-electron.0
OS: Darwin arm64 20.3.0

Additional context
Sample file:

		<html lang="en">
			<head>
				<meta charset="UTF-8">
				<meta name="viewport" content="width=device-width, initial-scale=1.0">
				<script type="module" src="${toolkitUri}"></script>
				<script type="module" src="${applyThemeUri}"></script>
				<link href="${codiconStylesUri}" rel="stylesheet" />
				<link href="${codiconFontUri}" rel="stylesheet" />
				<title>Hello World!</title>
			</head>
			<body>
				<h1><span class="codicon codicon-rocket"></span> Hello World!</h1>

				<vscode-design-system-provider use-defaults>
					<vscode-button>Howdy!</vscode-button>
				</vscode-design-system-provider>

				
				<vscode-breadcrumb-item href="#">
					Breadcrumb Item Label
					<svg slot="start" class="codicon codicon-symbol-method"></svg>
					<svg slot="separator" class="codicon codicon-chevron-right"></svg>
				</vscode-breadcrumb-item>
			</body>
		</html>

logs

“Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”

GitHubTags: #A11yMAS;#A11yTCS;#A11ySev2;#SH_VscodeWebviewUiToolkit_Aug2021;#Webview UI Toolkit for Visual Studio Code;#Win32;#FTP;#DesktopApp;#WCAG4.1.2;#AINotInScope;

Environment Details:

Application Name: Vscode Webview Ui Toolkit
Windows Version: Win10

Repro Steps:

1. Launch VS Code
2. Open WebView UI Toolkit: All Component extension
3. Tab to any Data Grid open developer tool by hitting "ctrl+shift+i" and check if name property is provided for any data grids

Actual:

No name property is provided for any of the data grids like "default data grid" etc.

Similar issue is with all the "Panels" in the "Panels" scenario.

Expected:

The unique name property should be provided for all the data grids.

User Impact:

Screen reader users will not get the proper information about the data grids

Feature/component description

This component enables consumers to render a context menu on arbitrary elements within their extensions.

Screenshots/references

https://github.com/microsoft/fast/blob/eeb625e346a54da4c1f338eb90341a6e2d9ddb83/packages/web-components/fast-components/src/anchored-region/index.ts

Describe the bug

Based on Storybook accessibility audits, must ensure that checkboxes have an accessible label.

To reproduce

Look at the accessibility tab for the icon button story:

https://microsoft.github.io/vscode-webview-ui-toolkit/?path=/story/library-checkbox--default

Expected behavior

Checkboxes should have accessible labels.

Screenshots

Desktop (please complete the following information):

• OS Version: macOS 11.5
• Toolkit Version: v0.6.2

Describe the bug

The tag and badge toolkit components do not have discernable borders when VS Code is using the high contrast theme.

To reproduce

The easiest way to reproduce is:

• Open the all-components sample extensions
• Set the VS Code theme to high contrast

Expected behavior

I believe these components should incorporate high contrast design tokens so component borders are clear to people with visual impairments.

Screenshots

An example of what a component with a high contrast border looks like:

Desktop (please complete the following information):

• OS Version: macOS 11.5.2
• Toolkit Version: v0.6.1

First off -- awesome stuff! I'm really excited to see how this is progressing.

In the example, there was a need to have a setThemeEventListener to listen for theme changes, and then posts a message to the webview. We can achieve the same effect completely within the webview to avoid any dependency between the extension and the webview.

In GitLens, I setup a MutationObserver and just watch for changes to the body's class to trigger theme updates:

https://github.com/eamodio/vscode-gitlens/blob/913c0606d03befc4f025d325a53df22be9df8221/src/webviews/apps/shared/theme.ts#L78-L79

That way your js library could just add that hook and keep things totally self contained.

Describe the bug

Not completely sure if this should be categorized as a bug or not, but the default behavior shipped by the FAST Combobox is that a user can click the topbar element to expand it but cannot click the topbar element to collapse it. The only way to collapse a Combobox is to click outside of its bounding area.

FAST Example
Toolkit Example

This runs in contrast to the Dropdown (FAST Select) which can be expanded and collapsed by clicking the topbar element.

FAST Example
Toolkit Example

To reproduce

Steps to reproduce the behavior:

1. Create a vscode-combobox
2. Click the element to open
3. Try to click the element again (it will not collapse)

Expected behavior

My expectation is that the behaviors of the Combobox and Dropdown should be aligned. Or at the very minimum clicking the Combobox chevron should collapse the Combobox.

Additional context

@daviddossett Your feedback on this would be helpful because I'm not sure what the common behaviors for a Combobox are (i.e. maybe this is a common UX convention for Comboboxes?).

Feature/component description

Currently, a number of component styles are still implemented with magic values which should be refactored into design tokens––especially color tokens that need to be associated with the correct VS Code theme color CSS variables.

Use case

This work is required to meet the June 2021 iteration plan goal of fully configuring component theming.

This plan captures our work in August. We will ship continuously throughout the month towards the public beta release.

Our goal for this iteration is to gather feedback from early adopters of the toolkit and to fix issues and improve the toolkit along the way.

Plan Items

Below is a summary of the top-level plan items.

Components

• Fix data grid column width bug
• Research FAST Foundation v2.0

Theming, Styles, and Layout

Accessibility

• Validate that VS Code accessibility standards are being met
• Address Storybook accessibility warnings

Infrastructure

• Update Storybook to v6.3.0

Testing

• Finish unit tests for applyTheme utility

Docs

• Create and add toolkit illustration(s)
• Create design patterns and guidelines

Sample Extensions

Feature/component description

Given that badges and labels are fairly distinct styles and use cases, I think it makes sense to have them split into Badge and Tag components, which render numbers and text respectively. This also means we don't put the burden on authors to specify the "circular" attribute on the badge.

Note that the Badge has several variants for size/color in the design toolkit. Need to clarify if we need to match these 1:1.

Screenshots/references

Figma Components

Actual:

NVDA does not announces the name of the selected tab items like "Problems" when navigating using tab key.

Similar issue is observed with Jaws

Similar issue is with all the Panels and Panel's tab item

Expected:

NVDA should be announcing the name of the selected tab items like "Problems" when navigating using tab key

GitHubTags: #A11yMAS;#A11yTCS;#A11ySev2;#SH_VscodeWebviewUiToolkit_Aug2021;#Webview UI Toolkit for Visual Studio Code;#Win32;#FTP;#DesktopApp;#WCAG1.3.1;#NVDA;#Jaws;#STP;#AINotInScope;

Environment Details:

Application Name: Vscode Webview Ui Toolkit
Windows Version: Win10
Screen Reader: NVDA(2021.1), Jaws(2021.2102.34)

Repro Steps:

1. Launch VS Code
2. Open WebView UI Toolkit: All Component extension
3. Tab to Panels and tab to "Problems" tab item
4. Start NVDA use tab key and check the announcement

User Impact:

Screen Reader users will not get the proper information about the tab items in the panels

“Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”

Actual:

Issue1: The nvda does not announces the associated label for any checkboxes when navigating using tab key. The label is not provided in the aria-labelledby

Issue2: The name property is also not given to the checkboxes

Similar issue observed with jaws.

Similar issues observed with below scenarios:

1. Combo box
2. Dropdown
3. Number Field
4. Radio Group
5. Text Area(Default text area)
6. Text Field(Default text field)

Expected:

The nvda should be announcing the associated label for all checkboxes when navigating using tab key. The label should be provided in the aria-labelledby. Also the name property should be provided for all the checkboxes.

GitHubTags: #A11yMAS;#A11yTCS;#A11ySev2;#SH_VscodeWebviewUiToolkit_Aug2021;#Webview UI Toolkit for Visual Studio Code;#Win32;#FTP;#DesktopApp;#WCAG1.3.1;#NVDA;#Jaws;#STP;#AINotInScope;

Environment Details:

Application Name: Vscode Webview Ui Toolkit
Windows Version: Win10
Screen Reader: NVDA(2021.1), Jaws(2021.2102.34)

Repro Steps:

1. Launch VS Code
2. Open WebView UI Toolkit: All Component extension
3. Tab to Checkbox element and tab to first checkbox
4. Start NVDA and check the announcement

User Impact:

Screen Reader users will not get the proper information about the check boxes

“Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”

Feature/component description

Currently the calculations we use to specify component dimensions (as well as padding, margins, and more) are potentially difficult to read and understand at a glance.

Spike: investigate simplification to use only the 4px designUnit token and calculate values based only on that token.

Actual:

The NVDA does not announces the names of the menu items like "option label#1" when navigating using down arrow key. It only announces "blank" for all the menu items

Similar issue is observed with Jaws

Similar issue is with the "Dropdowns" scenario

Expected:

The NVDA should be announcing the names of the menu items like "option label#1" along with menu item numbering like 1 of 3 when navigating using down arrow key.

GitHubTags: #A11yMAS;#A11yTCS;#A11ySev2;#SH_VscodeWebviewUiToolkit_Aug2021;#Webview UI Toolkit for Visual Studio Code;#Win32;#FTP;#DesktopApp;#WCAG1.3.1;#NVDA;#Jaws;#STP;#AINotInScope;

Environment Details:

Application Name: Vscode Webview Ui Toolkit
Windows Version: Win10
Screen Reader: NVDA(2021.1), Jaws(2021.2102.34)

Repro Steps:

1. Launch VS Code
2. Open WebView UI Toolkit: All Component extension
3. Tab to Combo box element and tab to first combo box and expand it
4. Start NVDA use down arrow to navigate and check the announcement

User Impact:

Screen Reader users will not get the proper information about the menu items in comboboxes

“Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”

“Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”

GitHubTags: #A11yUsable;#A11yTCS;#A11ySev4;#SH_VscodeWebviewUiToolkit_Aug2021;#Webview UI Toolkit for Visual Studio Code;#Win32;#FTP;#DesktopApp;#AINotInScope;

Environment Details:

Application Name: Vscode Webview Ui Toolkit
Windows Version: Win10

Repro Steps:

1. Launch VS Code
2. Open WebView UI Toolkit: All Component extension
3. Tab to "Radio" buttons and select any one of them, and check if the visual representation is there.

Actual:

The "selected" and " not selected" radio buttons are not visually differentiable. There is not dot mark or tick mark after selecting any radio buttons.

Expected:

The "selected" and " not selected" radio buttons are not visually differentiable. There is not dot mark or tick mark after selecting any radio buttons.

User Impact:

Low vision users will find it difficult to view that if the radio button is selected or not

Currently, there are Storybook build errors that occur when using Webpack 5. This is a known issue and is being worked on by the Storybook team.

Watch this issue.

The toolkit has been temporarily moved back to Webpack 4 until this issue is resolved, at which point Webpack 5 will be readopted.

Various inconsistencies between inputs with regards to their border width and dropdown radius. Need to sync with core VS Code team to align on intended styling here. @hawkticehurst this can be assigned to me.

Storybook

Text field

Text area

Dropdown (focused)

In VS Code (Mac OS)

Looks like no border radius, 1px border width.

In the example code you showed loading the js file by getting its uri directly from the node_modules folder. That should be avoided, as we want extensions to be bundled and not ship their raw node_modules folder. So we should look into alternative ways of loading the library -- importing the js as a module or something along those lines. Though I'm not really thrilled with importing the lib directly into the extension, since it then adds size to the extension rather than just to the webview. So maybe there needs to be a bundle/webpack step or something that adds it in.

This plan captures our work in July. We will ship continuously throughout the month towards the public beta release.

Our goal for this iteration is to gather feedback from early adopters of the toolkit and to fix issues and improve the toolkit along the way.

Storybook

Plan Items

Below is a summary of the top-level plan items.

Components

• Data Grid
  • Fix rowsData method bug (#120)

Theming, Styles, and Layout

Accessibility

• Check that all accessibility Storybook tests are passing
• Check that VS Code accessibility standards are being met

Infrastructure

Testing

• Write unit tests for utility scripts

Docs

Sample Extensions

Problem

There is currently no FAST Foundation split button base component that can be used to implement a VSCode split button.

Solution

A custom implementation of a split button could be pursued, however, there is active work by the FAST team to create a split button spec that will eventually be implemented and added to FAST Foundation.

To maintain consistent usage of FAST Foundation across this library the progress of this base component will be monitored and when the base component is available the VSCode split button will be implemented and added to this library.

Typing in a text field, text area, or combo box will often trigger one of the default Storybook shortcuts. As a result, the various panes and sidebars will jank around or dismiss themselves.

Feature/component description

Let's investigate the need for a tree view component in the toolkit. Despite VS Code exposing an API for a tree view within a view, there have already been asks for a more flexible tree view both inside a webview view (e.g. Embedded Tools) and within a standard webview panel (e.g. Luna Paint).

Use case

Extension authors are asking for more functionality from a tree view such as filtering, pinning, and more.

“Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”

GitHubTags: #A11yMAS;#A11yTCS;#A11ySev2;#SH_VscodeWebviewUiToolkit_Aug2021;#Webview UI Toolkit for Visual Studio Code;#Win32;#FTP;#DesktopApp;#WCAG1.4.3;#AINotInScope;#ColorContrast;

Environment Details:

Application Name: Vscode Webview Ui Toolkit
Windows Version: Win10

Repro Steps:

1. Launch VS Code
2. Open WebView UI Toolkit: All Component extension
3. Tab to Breadcrumb+Breadcrumb Item
4. Open Color contrast analyzer and check if color contrast ratio of link texts of "src", "components", "index" are less than 4.5:1.

Actual:

The color contrast ratio of link texts of "src", "components", "index" are less than 4.5:1.It is 3.895:1

Expected:

The color contrast ratio of link texts of "src", "components", "index" should be greater than or equal to 4.5:1

User Impact:

Low vision users will find it difficult to view the links.

Feature/component description

There are a couple of components that can currently be set to any width. Based on conversations with @misolori it sounds like it might be smart to determine if a max-width should be set on these components and if so how long each should be.

Candidates For Max Width:

• Dropdown
• Number Field
• Text Area
• Text Field

Use case

This idea is that setting max-width(s) will ensure a greater level of alignment with the VS Code design language.

Feature/component description

Investigate need for utils that aid extension authors when laying out pages and components.

The main value prop of providing these utils is to avoid authors hardcoding one-off values for common scenarios like form stack spacing, grid layouts, and more.

Feature/component description

Add any missing documentation to Storybook for the Menu component

“Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”

GitHubTags: #A11yMAS;#A11yTCS;#A11ySev2;#SH_VscodeWebviewUiToolkit_Aug2021;#Webview UI Toolkit for Visual Studio Code;#Win32;#FTP;#DesktopApp;#WCAG2.1.1;#Keyboard;#AINotInScope;

Environment Details:

Application Name: Vscode Webview Ui Toolkit
Windows Version: Win10

Repro Steps:

1. Launch VS Code
2. Open WebView UI Toolkit: All Component extension
3. Tab to data grid "with variable column widths" and check if it is resizable using the keyboard with any key combination like "ctrl + shift + right arrow"

Actual:

The column headers of data grid "with variable column widths" are not resizable using the keyboard with any key combination like "ctrl + shift + right arrow"

Expected:

The column headers of data grid "with variable column widths" should be resizable using the keyboard with any key combination like "ctrl + shift + right arrow"

User Impact:

Keyboard only users will face difficulty in resizing the column headers width

Describe the bug

Based on Storybook accessibility audits, must ensure that icon buttons have an accessible label.

To reproduce

Look at the accessibility tab for the icon button story:

https://microsoft.github.io/vscode-webview-ui-toolkit/?path=/story/library-button--with-icon-only

Expected behavior

Icon buttons should have accessible labels.

Screenshots

Desktop (please complete the following information):

• OS Version: macOS 11.5
• Toolkit Version: v0.6.2

Describe the bug

Given that our Dropdown component is based on the component seen in VS Code's Settings page, we need to align the options list to at minimum take on the styling specified in the Figma toolkit.

Screenshots

Current

VS Code

“Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”

GitHubTags: #A11yMAS;#A11yTCS;#A11ySev2;#SH_VscodeWebviewUiToolkit_Aug2021;#Webview UI Toolkit for Visual Studio Code;#Win32;#FTP;#DesktopApp;#WCAG4.1.2;#AINotInScope;#DevTools;

Environment Details:

Application Name: Vscode Webview Ui Toolkit
Windows Version: Win10

Repro Steps:

1. Launch VS Code
2. Open WebView UI Toolkit: All Component extension
3. Tab to Button and tab to "with icon only" button , open developer tool (ctrl+shift+i) check if name is provided to it.

Actual:

The "with icon only" button has no name property assigned.

Expected:

The "with icon only" button should have name property assigned like for eg. here "with icon only" can be given as a name.

User Impact:

Screen reader users will not get the proper information about the button.

Feature/component description

I think it makes sense to create or update our sample extensions that align with our design patterns and guidelines outlined in the docs/figma examples/etc. It would be super helpful to have the two connect so authors don't see contradictions in our samples after reading the docs (or vice versa).

Open question: what kind of sample extensions would be good candidates to teach users best practices?

“Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”

GitHubTags: #A11yUsable;#A11yTCS;#A11ySev4;#SH_VscodeWebviewUiToolkit_Aug2021;#Webview UI Toolkit for Visual Studio Code;#FTP;#DesktopApp;#AINotInScope;#Win32;

Environment Details:

Application Name: Vscode Webview Ui Toolkit
Windows Version: Win10

Repro Steps:

1. Launch VS Code
2. Open WebView UI Toolkit: All Component extension
3. Tab to Button and tab to "with icon only" button check if it is permanently visible

Actual:

The "with icon only" button is not visible permanently on the screen. It appears when we hover over it or it receives keyboard focus

Expected:

The "with icon only" button should be visible permanently on the screen.

User Impact:

Low vision users will find it difficult to view that if there is button present or not

Currently, the VSCode Data Grid component gridData Storybook control renders the input JSON as a plain text box, which is hard to edit and view as a user.

Storybook has already merged a PR that adds a JSON editor/tree view control to the control options but it is currently published as a prerelease feature.

When the feature is added in a stable release update the gridData control to use this new feature.

Storybook Issue: storybookjs/storybook#12599
Storybook PR: storybookjs/storybook#12824

Feature/component description

Before public release, conduct a review of the entire toolkit to ensure that it is meeting VS Code extension accessibility standards.

Feature/component description

Lets ensure extension authors have great docs, walkthroughs, and/or other resources to help them build webview extensions that look and feel native to VS Code. This could take the form of Figma files, videos, docs, sample extensions, and more!

We'll need the green light from Marisol's C+AI accessibility team before moving to public beta.

“Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”

GitHubTags: #A11yMAS;#A11yTCS;#A11ySev2;#SH_VscodeWebviewUiToolkit_Aug2021;#Webview UI Toolkit for Visual Studio Code;#Win32;#FTP;#DesktopApp;#WCAG2.4.7;#Keyboard;#AINotInScope;

Environment Details:

Application Name: Vscode Webview Ui Toolkit
Windows Version: Win10

Repro Steps:

1. Launch VS Code
2. Open WebView UI Toolkit: All Component extension
3. Tab to "links" and tab to default link
4. Now hit tab key and check if focus is visible

Actual:

The keyboard focus is not visible after "default" link on pressing tab key. It goes on disabled link.

Similar issue is observed with scenarios:

1. Read only number field
2. Text Area

Expected:

The keyboard focus should be visible after "default" link on pressing tab key. The keyboard focus should go on next actionable control and not on disabled link.

User Impact:

Keyboard only low vision users will face difficulty in viewing the keyboard focus.

Describe the bug

When a Breadcrumb Item has been created with a custom element, the text underline hover style is still rendered leading to a peculiar/incorrect visual state.

To reproduce

Steps to reproduce the behavior:

1. Create a vscode-breadcrumb-item using a custom element (such as a button)
2. Hover over the custom element

Expected behavior

The text underline should not be rendered on hover when a custom element is used in a breadcrumb item.

Screenshots

Desktop (please complete the following information):

• OS Version: macOS 11.3.1
• Toolkit Version: 0.5.0

Feature/component description

Mirror core VS Code toolkit by creating a Figma Community file for easy duplication. Possibly mirror GH repo as well.

Describe the bug

When the vscode-data-grid component is used inside a VS Code webview environment (as compared to a web browser), the rowsData method results in a "Cannot read property of undefined" error.

To reproduce

Steps to reproduce the behavior:

1. Install and configure toolkit in a VS Code webview
2. Set the vscode-data-grid component data using the rowsData method
3. Run the extension in developer mode
4. The data grid will not render any data and an error will be logged to the console

Expected behavior

The data grid should render the data just like it does in the Storybook docs site.

Screenshots

Desktop (please complete the following information):

• OS Version: macOS 11.3.1
• Toolkit Version: 0.5.0