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

Screen reader: Access the status bar using the keyboard. #94677

Closed
jvesouza opened this issue Apr 8, 2020 · 49 comments
Closed

Screen reader: Access the status bar using the keyboard. #94677

jvesouza opened this issue Apr 8, 2020 · 49 comments
Assignees
Labels
accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues feature-request Request for new features or functionality verification-needed Verification of issue is requested verified Verification succeeded workbench-status Status bar
Milestone

Comments

@jvesouza
Copy link

jvesouza commented Apr 8, 2020

Perhaps this feature already exists and I am unaware, but the fact is that I cannot access the status bar using the keyboard. Using orca I can access some items from the status bar using the flat review mode, but this is not very comfortable.
The ideal in my opinion is that there was a command to move the focus to the status bar and that we could navigate between the items present using the arrows, tab and shift + tab. And when it was the case, that we could click on the items using the enter key.

CC @isidorn @marlon-sousa

@vscodebot
Copy link

vscodebot bot commented Apr 8, 2020

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

@isidorn isidorn self-assigned this Apr 8, 2020
@isidorn
Copy link
Contributor

isidorn commented Apr 8, 2020

@jvesouza thanks for the feedback. Atm we on purose do not make the status bar focusable. However having an explicit command to pass focus to the status bar makes perfect sense.

@bpasero what do you think? Once we have that command idealy users should navigate focus via key left / right or just tab to go through all the status bar items. If you do not have time to look into this I can also contribute if you provide some code pointers. Thanks

@isidorn isidorn added accessibility Keyboard, mouse, ARIA, vision, screen readers (non-specific) issues workbench-status Status bar labels Apr 8, 2020
@bpasero
Copy link
Member

bpasero commented Apr 8, 2020

Yes, a command to move focus into the status bar seems fine. The reason status bar is not in the list of things to "Tab" into is to reduce tab stops throughout the UI.

The control to render the status bar is statusBarPart

@isidorn
Copy link
Contributor

isidorn commented Apr 8, 2020

Ok, assigning to April so I look into this.

@isidorn isidorn added this to the April 2020 milestone Apr 8, 2020
@marlon-sousa
Copy link

Hello,

First of all thank you so much for the great work you are doing on vscode accessibility.

I am sorry for the delay on this comment, but let me show another point of view.

Usually, the status bar shows information contextual to a given operation. It can show the line / column the cursor is currently at, it can show the length or other information relative to a selection or it can show status on asynchronous information.

Usually, the status bar provides contextuual information that does not require the main focus to move from the task at hand. For example, one can look at selection information without touching the focus, otherwize the selection will be destroied.

Historically, screen readers have provided commands that allow blind users to check the status bar content also without moving their focus from the current task at hand. JAWS uses the insert (or other key configured as modifier) plus pagedown key, while NVDA uses the insert (or other key configured as modifier) plus end to achieve this goal.

I personally think that vscode should follow the standard behavior, to voice its status bar contents.

Sure, having a focus status bar command would be nice, but when I have test selected and just want to hear the selection length or otherwise want to know my line / column position I definitely would like to type a command and hear that information without leaving the text focus.

Thanks,
Marlon

isidorn added a commit that referenced this issue Apr 8, 2020
@isidorn
Copy link
Contributor

isidorn commented Apr 8, 2020

@marlon-sousa thanks for providing more details. And yes that makes perfect sense, I was unaware of a general way to make screen readers read out the status bar. Thanks for enlightening me.

I believe this is done by using the status role as described here https://w3c.github.io/aria/#status

Due to that I have just pushed a commit that our statusbar starts using the status role.
I can not verify if this works because I only have a super tiny mac keyboard which does not have the insert and pagedown key.
We should have a new insiders with this fix from Friday / Monday and you can try it out then and let me know if this does the trick. Or if you are keen on trying it out you ca build vscode by following this steps https://github.com/microsoft/vscode/wiki/How-to-Contribute

fyi @joanmarie @LeonarddeR for my use of status role and if there is something I might be missing here

@jvesouza
Copy link
Author

jvesouza commented Apr 8, 2020

@marlon-sousa I agree that reading the contents of the status bar is essential. However, I believe that being able to access the actions from the status bar would also be very useful.

By the way, I didn't find information about the current line and column in the status bar. I don't know if the information is really missing or if the orca was unable to identify it.

@joanmarie
Copy link

@isidorn I just built VSCode. I have good news and bad news.

  • Good news: The container has a role of statusbar
  • Bad news: It lacks children, accessible text, a name, etc.

The latter means Orca has nothing to present.

@joanmarie
Copy link

Update: I quit Orca and relaunched VSCode and see status bar children. But Orca is still not finding them. So I'll investigate more tomorrow on that front and get back to you with an answer and possibly a change to Orca.

In the meantime, there is a potential issue with using this role: The ARIA status role is a live region. Screen readers typically announce changes in live regions. So we might find that screen readers suddenly start announcing things automatically and contrary to what users want.

At least in the case of Orca, one can disable live region notifications on a per-object basis. Not sure about other screen readers.

@isidorn
Copy link
Contributor

isidorn commented Apr 9, 2020

@jvesouza good catch, there was an issue with line and columns missing when screen reader is attached. I just pushed a fix for that. I believe this was originaly added by @alexdima to not make screen readers too chatty.
Also note that all actions in the status bar are accessible via the command palette. So my personal preference is that we try to make this status role work and on top of that you can use different commands in the command palette. Though let's see how it goes.


@joanmarie you are right, the status role is definetly too spamy when I try it out with VoiceOver and NVDA. Whenever I change a cursor possition, the screen reader would say the content of the status bar which is a bad experience. So for now I could return to using the contentinfo role for the status bar. However looking at the aria spec only one part should have the contentinfo which out titlebar already has, thus going with complimentary.

So idealy we would need a role like the status but that is not chatty as status. I am open for suggestions @joanmarie @LeonarddeR @cookiecrook @MarcoZehe
If we do not find a good role I would have to introduce a vs code command that passes focus to the status bar.

@MarcoZehe
Copy link
Contributor

role="status" has an implicit aria-live="polite" attached to it. To keep the semantic that this is the status bar, but not make it chatty, you could do role="status" aria-live="off".

@isidorn
Copy link
Contributor

isidorn commented Apr 9, 2020

@MarcoZehe great suggestion. This actually seems to work just fine. I just pushed it.

@joanmarie let me know how the investigation on the Orca side goes, looking at the HTML content the structures seem just fine. The only missing thing is that all the elements have the title set, but none of them have an aria-label set. Is there a rule of thumb that if the title is descriptive enought aria-label should not be set, or we should always set it? We do the same for all our actions, we just set the title.

@LeonarddeR
Copy link

Let me share some thoughts here:

  1. While all actions from the status bar are accessible from the command palette, for sighted users, they are available directly from the status bar. Therefore, I'd prefer a solution where the status bar can gain focus.

  2. Might be another subject, but I just noticed that VS Code is doing nothing with the f6 // shift+f6 key sequences. In MS Office products, using F6 gives you quite interesting possibilities to access areas of the screen that might otherwise be inaccessible. IN my case for example

    • Opening word focuses the document area
    • Pressing F6 focuses the status bar. I can move through items on there with arrow keys and tab
    • ANother press of F6 brings me to the ribbon
    • If I would have toolbars active which I tend to avoid, than pressing F6 can bring me to them, to the search field, to notifications about auto save and protected view, etc.

    I think that implementing this sequence in VS Code can really improve keyboard accessibility if it would allow you to jump to the first item in several areas of the screen. I believe Firefox has a similar approach, so may be @MarcoZehe would like to comment on this as well.

@MarcoZehe
Copy link
Contributor

Indeed, adding F6 and Shift+F6 to move to various important anchor points within VS Code would be awesome. We use this in Firefox to go to the address bar, the main content, the developer tools if they're open, and any doorhangers (alert popovers) that might be open. Chrome and Edge also use F6 for this purpose to navigate various areas of the screen. Teams and Slack do the same. So, there are plenty of examples, this is a known and useful keyboard navigation pattern.

@isidorn
Copy link
Contributor

isidorn commented Apr 9, 2020

@LeonarddeR thanks for providing feedback.

  1. This should be solved if the screen reader command that @marlon-sousa describes works as I suspect. It places the focus on the status element. As pointed out it should be triggered via insert + end
  2. This makes sense. I just tried it out and I could not get it to work on Chrome and Teams. Though it works for Word and Firefox. Note that I am on macOS, so I was wondering if this shortcut would work for all platforms and it seems it does.

Luckily this keyboard shortucts does not seem to be taken in VS Code, so we might use both F6 and Shift + F6 (unless you are debugging when it Pauses).
These command would be called "Focus Next Part" and "Focus Previous Part" and the focus would move cyclicaly in the following proposed order
Editor -> Status Bar > Side Bar > Panel > Main Menu > Editor
Let me know if htis order makes sense, or should we even traverse the Main Menu

@MarcoZehe
Copy link
Contributor

There are shortcuts for the main menu on all platforms: Alt or F10 on Windows and Linux, and CTRL+F2 (CTRL+FN+F2 maybe) on Mac, and with VoiceOver there's an additional CTRL+Option+M. So the main menu bar may not need to be included.

What would the "panel" contain?

Also note that Insert+End will read the status bar normally, not focus it, unless, IIRC, pressed twice, which may or may not work depending on the application, and not all screen readers have this or a similar shortcut.

@isidorn
Copy link
Contributor

isidorn commented Apr 9, 2020

Ok, makes sense. Agree that we can leave out the Main Menu.
Panel contains things like the Output, Terminal, Debug Console, Problems View. it is very similar to the SideBar but it is layed out on the bottom, while sidebar is layed out on the left and have different views associated with them.

@marlon-sousa
Copy link

Hello,

Some thoughts here:

1- The status bar can not, for the life of mine, be a live region. It can't because it keeps changing all the time (as supposed) and one while writing or debugging or doing whatever operation can not be interrupted and warned about all changes all the time. So please follow @MarcoZehe suggestion and make aria-live = off.
2- We should be focusing first in exposing the status bar in a way where a screen reader command reads its content, thus enabling productivity of blind programmers by letting them verify quickly and without loosing focus on their task the status bar contents, on an on-demand operation by pressing a key. While may be not every screen reader has this functionality out of the box, Windows is covered by NVDA (free) and JAWS (paid) which I believe is already a extremely big win. @joanmarie can confirm but I strongly believe that this would be the case for Orca also.
4- @isidorn you are using a mac ... with Windows I suppose running? If so, you can do your testing, because NVDA has settings to use the capslock key as its modifier, and the read status line command can be assigned to other keys if you need.
4.1- To activate caps lock as modifier, go to the NVDA menu and, in preferences, select settings. In the dialog, select keyboard, and you will see the list of modifiers as one of the options. Enable caps lock and there you go.
4.2- In order to remap the read status line command, go to nvda menu and select preferences. Then, select input gestures and in the filter type status. You will see an option under system focus that reads the application status. Click in add and (I suggest) press capslock + g. When the context menu arises, choose all layouts. Then, close that Window by pressing ok.
4.3- Go to the notepad and press capslock + g. You should hear the status bar being read.
5- The idea of using f6 key as @LeonarddeR suggested is great. One of the most time consuming task I have to do is alternate between the editor and the edit field of the terminal when it is opened, or between the explorer and the editor, specially if I give up the explorer and just want to go back quickly to the editor to read something. Having f6 key implemented circling between first element of screen areas would be great. I just think that this key should be reassignable by the user (if they ever need) and should debugging take place it should be de prioritized.
4- Let the menu bars out of the ring, as previously said the alt or f10 keys are dedicated exclusively to this task ense we are covered.
5- If you ever has any difficulty testing your implementations with a screen reader do not exitate to ask. All of us will help you.

Thanks!

@marlon-sousa
Copy link

On another note ...

I have been trying to build vscode on Windows now for a good number of hours without success.

I know that this is not the place to ask, but I have an extremely strange error that I have found no solution, even looking for it on vscode issues.

If ** and only if ** you know what it is it would be very helpful because this would allow me to experiment with accessibility stuff right here and help more quickly.

Command: node-gyp rebuild
Arguments:
Directory: C:\projetos\vscode\node_modules\native-is-elevated
Output:
C:\projetos\vscode\node_modules\native-is-elevated>if not defined npm_config_node_gyp (node "C:\Program Files\nodejs\nod
e_modules\npm\bin\node-gyp-bin\....\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "" rebuild )
gyp info it worked if it ends with ok
gyp info using node-gyp@3.8.0
gyp info using node@12.0.0 | win32 | x64
gyp ERR! configure error
gyp ERR! stack Error: Command failed: c:\python37\python.exe -c import sys; print "%s.%s.%s" % sys.version_info[:3];
gyp ERR! stack   File "", line 1
gyp ERR! stack     import sys; print "%s.%s.%s" % sys.version_info[:3];
gyp ERR! stack                                ^
gyp ERR! stack SyntaxError: invalid syntax
gyp ERR! stack
gyp ERR! stack     at ChildProcess.exithandler (child_process.js:304:12)
gyp ERR! stack     at ChildProcess.emit (events.js:196:13)
gyp ERR! stack     at maybeClose (internal/child_process.js:1000:16)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:267:5)
gyp ERR! System Windows_NT 10.0.18362
gyp ERR! command "C:\Program Files\nodejs\node.exe" "C:\Program Files\nodejs\node_modules\npm\node_modules\node
-gyp\bin\node-gyp.js" "rebuild"
gyp ERR! cwd C:\projetos\vscode\node_modules\native-is-elevatedOn my windows 10 when running yarn I have this error:

Strangely, this line gyp ERR! stack Error: Command failed: c:\python37\python.exe -c import sys; print "%s.%s.%s" % sys.version_info[:3]; seems to be trying to use python 2 syntax on a python 3 environment. I am out of ideas.

@marlon-sousa
Copy link

Well, installed python 2.7 and now I am downloading old vs 2015 stuff. Should be, hopefully, able to build and test.

@isidorn
Copy link
Contributor

isidorn commented Apr 9, 2020

@marlon-sousa thanks for feedback.

  1. yes, we have already pushed aria-live = off
  2. Makes sense
  3. Yes I have a Win VM, I will check it out based on your tips
  4. We will leave the Main Menu out of the cycle
  5. All command keybindings are reassignable in vscode via File > preferences > keyboard shotcuts. And this one will be as well
  6. for your build troubles make sure to have all the prerequests installed as specified here https://github.com/microsoft/vscode/wiki/How-to-Contribute#prerequisites

@joanmarie
Copy link

@isidorn Works for me too. Thanks! Hopefully @jvesouza concurs?

@marlon-sousa
Copy link

@joanmarie can you confirm what Orca is saying if you checkout master at current commit?

For me, NVDA is saying the following:

Remote
vscode (Git) - master
vscode (Git) - Synchronize Changes
1 Errors
Notifications
JavaScript
CRLF
UTF-8
Tab Size: 4
Ln 3, Col 1
Screen Reader Optimized

Thanks,
Marlon

@marlon-sousa
Copy link

I am asking because it seems to be repeating some information.

For example, using document mode (e.e reading with arrows) I listen:

Remote
master
vscode (Git) - Synchronize Changes
1 0
Notifications
JavaScript
CRLF
UTF-8
Tab Size: 4
Ln 273, Col 50 (8 selected)
Screen Reader Optimized

@joanmarie
Copy link

@marlon-sousa I am not currently in a position to try, but I'm pretty sure we see the same thing in Orca.

When reading generic text objects like divs in browse mode (i.e. reading with arrows), Orca completely ignores the names of those text objects because (imho) generic text objects which are caret navigable and not focusable arguably shouldn't have names. I believe others share my view -- potentially including NVDA developers (though I cannot speak to that with certainty).

But when Orca's command to present the status bar is used, Orca examines the children and if those children have names, it happily accepts those names without question. Whether or not Orca should do that is another matter. But that's what Orca does at the present time. Perhaps that's what NVDA does as well?

Regardless, I guess the question is: Is there information which you (and @jvesouza and other screen reader users) feel is extraneous? If the answer is "yes", then that sounds like a feature request for @isidorn.

@jvesouza
Copy link
Author

@isidorn Works for me too. In my opinion, the screen reader information in the status bar could be removed.
@joanmarie Navigation on the status bar with flat review mode is not good. Could it be possible to improve?

@joanmarie
Copy link

@jvesouza Can you open a new bug here for that? I'm not sure yet how much of the work needs to be done in Orca versus (potentially) how much we might wish to change in VSCode. But it would be nice to have an issue in which to track it.

@marlon-sousa
Copy link

@joanmarie,

Thanks. I asked for confirmation about the read content because I wanted to compare screen readers behavior. For me, the repeated information on my status bar read is something that could be improved, but this is very acceptable at the current state.

if I were to prioritize something now, it would be the f6 ring, as this would be really great to have.

I also haven't, until now, found any accessibility regression.

@isidorn thank you for implementing and for the patience with my questions. Building vscode was kit a challenge, but now that I know how to do it I will be able to test and validate stuff more easily.

A last question for you and @joanmarie: I am not a front end / web developer. I want to know if the accessibility tree can be seen somehow from within vscode itself in a debug section or by activating dev tools or if this has to be checked in the screen reader side of things. I ask this because I think once I learn how to inspect this it will be easier for me to help you guys like @joanmarie did by finding the double status issue.

isidorn added a commit that referenced this issue Apr 13, 2020
@isidorn
Copy link
Contributor

isidorn commented Apr 13, 2020

Hi. Thanks for feedback.
Follow up items:

Since I read positive feedback about this change I am adding the label verified. And follow up work we can discuss in the follow up issues.


@marlon-sousa I have fixed the duplication that you encountered via 6ad9dd4

There is not way just to see the accessibility tree of vscode, but since VS Code is built on top of electron which uses Chrome we use HTML for rendering, so it is possible to inspect that. F1 > developer tools > Elements tab > you can se the HTML structure of the whole content. Please note that these are Chrome developer tools and I am not sure how accessible it is.

@isidorn isidorn added feature-request Request for new features or functionality verification-needed Verification of issue is requested verified Verification succeeded labels Apr 13, 2020
@jvesouza
Copy link
Author

@isidorn I think I found a small problem. When I access the status bar I get the following information:
'Remote abcde_fgh (Git) - xxx* abcde_fgh (Git) - Publish Changes 19 Warnings, 13 Infos $(database) Connect Notifications Tweet Feedback $(info) $(thumbsup) Properties CRLF UTF-8 Spaces: 4 Ln 1, Col 14 Screen Reader Optimized'
There are three pieces of information that are unknown to me:
$(database), $(info) and $(thumbsup).

I believe that this information must be related to some extension installed by me in vscode.

@isidorn
Copy link
Contributor

isidorn commented Apr 13, 2020

@jvesouza good catch, and you are correct, that is coming from extensions.
The issue was that we have this hidden syntex when $( is used that we actually render an icon in the status bar.
Due to that I have pushed a following heuritc: if an extension contributes a status bar with an icon use the tooltip for the arialabel, otherwise use the original text.
So now I think it should behave better. Thanks

@jvesouza
Copy link
Author

@isidorn It seems that this feature has stopped working, at least with the orca. When I use the command to read the status bar nothing is read.

@MarcoZehe
Copy link
Contributor

Confirmed also with NVDA on Windows. I now get the message "No statusbar".

@isidorn
Copy link
Contributor

isidorn commented Apr 23, 2020

Hmm thanks for reporting. The only change I did in this area is to put the aria-label on the label container not on parent c6d841c
But I did that 7 days ago.
From your comments I think this got broken in the past 24hours, it was workign yesterday, correct?

I still see that the statusbar correctly has the role status. Investigating more... Ideas are welcome!

@jvesouza
Copy link
Author

Yes, it was working yesterday.
I'm probably wrong, but I suspect the following commit:
commit 518c83b
Author: Miguel Solorio miguel.solorio@microsoft.com
Date: Wed Apr 22 13:44:36 2020 -0700

Polish status bar (make it shorter)

I have no technical basis to suspect this commit, it's just a feeling!

@isidorn
Copy link
Contributor

isidorn commented Apr 23, 2020

Thanks @jvesouza
Looking at the commit it is mostly css design changes so that is probably not the one.
I will do some git bisecting now to find the cause. Can you just let me know how do you trigger your "Status" command? And if you do F6 is everything read out nicely?

@jvesouza
Copy link
Author

You need to find out in the orca preferences the keystroke that is associated with the speaks the status bar command.
In the orca preferences screen there is a tab called key bindings.
It is possible on this tab to create or modify a key association for a command.
The behavior of the f6 key does not appear to have changed.

@isidorn
Copy link
Contributor

isidorn commented Apr 23, 2020

Ok configured it to be shift + 1 hehe
Now I am bisecting...

@isidorn
Copy link
Contributor

isidorn commented Apr 23, 2020

Strange for latest VS Code insiders and for latest out of source I can not reproduce the issues you are hitting. I am using latest VS Code insiders from 23 April commit d342048 Status bar always gets nicely read to me.
I can also try with NVDA, since I just tried ORca.

@joanmarie can you maybe check if you can repro? Though the issue is probably in vscode since @MarcoZehe also sees it with NVDA

@jvesouza
Copy link
Author

@isidorn OOPS! My mistake.
Please forgive me, I was using the wrong version of orca in the tests.

@jvesouza
Copy link
Author

I restarted my machine and by default version 3.36 of orca is started. This version does not yet have access to the status bar implemented.
Again I apologize for the failure, I think I need a coffee!

@isidorn
Copy link
Contributor

isidorn commented Apr 23, 2020

@jvesouza Ok, so you are good :)
Now let's see what issue @MarcoZehe is hitting. @MarcoZehe did this start happening in the last 24hours, or might it be my commit from 7 days ago? When you press F6 does the status bar get nicely read for you or not?

@MarcoZehe
Copy link
Contributor

I am on the latest Insider now. And the status bar is read as "Status bar" when I hit F6. If I turn browse mode on, NVDA-Key+Space, I can read the items on the status bar. I thought I tested the status bar yesterday or on Tuesday, and it worked then. It definitely does not work now.

@github-actions github-actions bot locked and limited conversation to collaborators May 25, 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 feature-request Request for new features or functionality verification-needed Verification of issue is requested verified Verification succeeded workbench-status Status bar
Projects
None yet
Development

No branches or pull requests

7 participants