Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.80.1 OS Version: any The role of the aria status container is currently "complementary" It is a landmark role (refers to ) thus assistive technology will identify it as a navigation destination while it may contain nothing. The role should be "status".
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.80.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
is there any history here about why we went with ?
We already use role "status" for the status bar. And my understanding is there should not be two elements with that role. Screen readers have an action to read the content of the status bar. And we want screen readers to read the bottom status bar, not the hidden aria field.
can you explain what you're thinking is not working currently with this approach?
with Edge/Chrome a file, find some characters with the find box and press up/down arrow keys to show some history. (this is to generate some content in the complementary div, refers to ) the find box and do whatever your work. (the content in the complementary div will remain). landmark with assistive technology. (refers to ) I use JAWS on Windows, press Insert+Ctrl+R will show there's a complementary region on the page, which doesn't make sense. If I embed monaco-editor into a page with other regions. Screen reader users will often get structure of the page with the landmarks and the complementary region is confusing. Thank you very much for explaining why it can't be status. It's not a big problem but a landmark role looks not suitable for aria status. Not sure if other role fits.
do you have thoughts on what role should be used here?
I completely agree that the role should be status.
Thanks Roberto. But will that confuse screen readers for the command that reads the status bar? Am I misunderstanding something in my comment here
The is the equivalent of aria-live="polite". The way in which it works in VS code, particularly with NVDA, has been a complete surprise to me. I wonder if it has to do with the fact that the role has been given to the footer element. What is evident is that NVDA recognizes the status bar as a status bar, and if I remove the role it doesn't. Another way to address the issue that was filed would be to replace the complementary role by that has no semantic value, or simply remove the role since the container is just a generic div that doesn't require a role. I would love to contribute with the fix myself once we decide how to go about it.
I'm in favor of removing the role since it's not needed here
Removing the role makes great sense to me. PR is very welcome!
Submitted .

Discussion:
const createStatusContainer = () => { const element = document.createElement('div'); element.className = 'monaco-status'; <del> element.setAttribute('role', 'complementary'); </del> element.setAttribute('aria-live', 'polite'); element.setAttribute('aria-atomic', 'true'); ariaContainer.appendChild(element);