Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VS Code Accessibility Call - June 2020 #99916

Closed
sana-ajani opened this issue Jun 11, 2020 · 3 comments
Closed

VS Code Accessibility Call - June 2020 #99916

sana-ajani opened this issue Jun 11, 2020 · 3 comments
Assignees
Labels
accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues
Milestone

Comments

@sana-ajani
Copy link
Contributor

sana-ajani commented Jun 11, 2020

Each month, we try to hold a call where users in our accessibility community can give feedback, bring up problems, and share accessibility practices with members of our team. The June call will be held on Tuesday, June 23 at 11am EST / 5pm CEST / 8:30pm IST.

Based on feedback from the last call, we would like to limit people on the call so that we facilitate richer communication and get more focused feedback. Thus, we are asking those who are interested in participating to fill out the sign up link below:

Sign up to participate

Agenda:

We will reach out to confirm those who will be participating in the call and send you a Microsoft Teams link to join the call. We will post a link to the recorded video at the end of the call.

@isidorn isidorn added the accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues label Jun 12, 2020
@isidorn isidorn added this to the June 2020 milestone Jun 12, 2020
@sana-ajani
Copy link
Contributor Author

sana-ajani commented Jun 23, 2020

Video recording: https://youtu.be/4Vwh7mWu-W8

Meeting notes:

Settings:

  • What about settings that contain lots of keys? How can a user edit a key? If no new keys can be added, then display all the keys/values in a tabular format; if more keys can be added, show an "add" button

  • How can we convey to a user that this is an object setting? If a setting is an object, maybe we include it in the left pane?

    • Left side is a set of things that can be collapsed or expanded, right side is a flat list, with no object type settings or hierarchies…having nesting in the right pane may be confusing
    • Depends on how often a user interacts with these settings
  • What about if a user navigates past this object setting? Is it obvious if the user tabs away? Is the setting read as the object setting and property name or just the setting property name?

Debugging:

@isidorn
Copy link
Contributor

isidorn commented Jun 24, 2020

@sana-ajani thanks a lot for capturing notes.

Since this meeting has taken place as planned and we have createn follow up issues I am closing this issue.
Even though the issue is closed feel free to comment here if needed.

@9at8 should we create some issue for settings to capture the feedback or the current issues already capture it well enough?

@isidorn isidorn closed this as completed Jun 24, 2020
@9at8
Copy link
Member

9at8 commented Jun 25, 2020

I think most of the feedback that I needed was different ways/expectations for editing object settings from the GUI, and I don't think we need to create more issues for that.

@github-actions github-actions bot locked and limited conversation to collaborators Aug 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues
Projects
None yet
Development

No branches or pull requests

3 participants