Giter Club home page Giter Club logo

rushstack-websites's Introduction

Rush Stack Websites

Main CI Latest Deployment
Main CI Latest Deployment

The following websites are maintained in this monorepo:

Targets

The Docusaurus websites in this monorepo support a concept called "target", which describes the environment sites are being built for. There are 3 possible targets:

"local"

The local target is intended for use when a Docusaurus development server is running locally. This target will automatically be selected if you run rushx start in any of the website projects.

You can also force this target by setting the environment variable TARGET=local.

"fork"

The fork target is intended for use when you are building static Docusaurus sites for deployment, but you'll be deploying them to GitHub Pages on your fork of the rushstack-websites project. This is useful for deploying demo sites to share with others, to test on phones and tablets, etc. This target will automatically be selected if you run a production build (rushx build) of a website project and you have cloned a fork of the rushstack-websites project.

You can also force this target by setting the environment variable TARGET=fork.

"prod"

The prod target is intended for use when you will be deploying a website project to GitHub Pages in its live production repo. Typically this target is only used by a CI pipeline, and it is automatically selected if you run a production build on a clone of the microsoft/rushstack-websites repo.

You can also force this target by setting the environment variable TARGET=prod.

Deploying a fork

To facilitate testing of multi-site changes, you can opt to build and deploy all of the website projects at once from a fork of rushstack-websites. To do so, first make sure you've forked the project and cloned your fork locally, and then run:

rush install
rush build
GIT_USER=<your-git-username> rush deploy-fork

The commands above will automatically build all of the supported websites with TARGET=fork, then deploy them in a group to the gh-pages branch of your forked repo. You can then access these sites via individual site paths, for example:

https://<your-git-username>.github.io/rushstack-websites/rushstack.io/

Cross-site links between the different sites will automatically be linked up to navigate to your deployed versions of those sites.

Deploying to production

The production Rushstack websites are deployed periodically by the maintainers using an Azure DevOps pipeline. Check the badge at the top of this README for the latest status and deployment history.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Legal Notices

Microsoft and any contributors grant you a license to the Microsoft documentation and other content in this repository under the Creative Commons Attribution 4.0 International Public License, see the LICENSE file, and grant you a license to any code in the repository under the MIT License, see the LICENSE-CODE file.

Microsoft, Windows, Microsoft Azure and/or other Microsoft products and services referenced in the documentation may be either trademarks or registered trademarks of Microsoft in the United States and/or other countries. The licenses for this project do not grant you rights to use any Microsoft names, logos, or trademarks. Microsoft's general trademark guidelines can be found at http://go.microsoft.com/fwlink/?LinkID=254653.

Privacy information can be found at https://privacy.microsoft.com/en-us/

Microsoft and any contributors reserve all others rights, whether under their respective copyrights, patents, or trademarks, whether by implication, estoppel or otherwise.

rushstack-websites's People

Contributors

aribaskar-jb avatar benkeen avatar bvanjoi avatar cuining avatar depressedx avatar elliot-nelson avatar gigara avatar iclanton avatar iola1999 avatar kamontat avatar kenrick95 avatar leiyunkang7 avatar lincong1987 avatar luxcium avatar lvqq avatar lyandzao avatar microsoft-github-operations[bot] avatar microsoft-github-policy-service[bot] avatar moonrailgun avatar octogonz avatar openhacking avatar peoren avatar robertf224 avatar tanimodori avatar thomazcapra avatar tobemaster56 avatar wanderwang avatar woutwo avatar wyhooo avatar younesah15 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rushstack-websites's Issues

Shell commands in documentation contains syntax errors

Hi, thank you for working on this project.

As a developer investigating using Rush on a project
And reading the documentation
I want to be able to follow the getting started instructions
In order to see Rush in action

Given the shell commands in the Rush documentation
For example $ npm install -g @microsoft/rush
When I copy and paste them into my terminal
I expect that the commands will work
But I encounter these errors
In fish shell (my main terminal)

fish: Expected a variable name after this $

And in a Bash shell

zsh: command not found: $

Operating system: Mac OS
Terminal: iTerm

[TSDoc> Playground]: 'Selected' tab item such as 'DOM' is not accessible with keyboard on renavigation under 'Playground'.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/
Screen reader: Narrator

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Turn on the narrator through Ctrl+ windows+ Enter key.
  3. Navigate to the 'Playground' link and activate it.
  4. Navigate to the 'DOM'tab item and activate it.
  5. Now, renavigate on the 'DOM' tab item.
  6. Observe the issue.

Actual Result:
On renavigation, selected' tab item such as 'DOM' is not accessible with keyboard.

Expected Result:
'Selected' tab item such as 'DOM' should be accessible with keyboard on renavigation under 'Playground'.
Screen reader should announce the state information along with the position such as 'DOM Tab item selected 2 of 5'.

User Impact:
Keyboard dependent and screen reader user will get impacted as user will not not be able to renavigate back to the selected control and will not be able to make track of the content properly.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"
2   Screen reader is not announcing the disabled state nor does it announce position for the list item under ‘Direct access’ section

MAS2.1.1.Selected.tab.item.under.DOM.is.not.accessible.with.keyboard.under.playground.mp4

[TSDoc> Search]: In scan mode narrator focus is landing multiple times on the search suggestions which is present under 'Search' dialog.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/
Screen reader: Narrator

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Turn on the narrator through Ctrl+ Windows+ Enter key and press caps lock+ space bar key to turn on the scan mode.
  3. Navigate to the 'Search' button through tab key and activate it.
  4. Navigate to the 'Search docs' edit field and type any keywords.
  5. Navigate to the appeared search suggestion through up/dowwn arrow key.
  6. Observe the issue.

Actual Result:
In scan mode narrator focus is landing multiple times on the search suggestions which is present under 'Search' dialog. i.e with down arrow key it announce as 'Blank'> link> graphic> 'From the debug combobox....> Building the projects.

Expected Result:
In scan mode narrator focus should not lands multiple times on the search suggestions which is present under 'Search' dialog.

Notes:
Same issue is repro with NVDA.

User Impact:
Screen reader user will get impacted as user will get irritate when focus lands multiple times on scan mode due to which user will have difficulty in navigating or in tracking the content.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/meaningful-sequence.html

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"

MAS1.3.2.In.scan.mode.screen.reader.focus.is.landing.multiple.times.on.the.search.suggestions.mp4

[TSDoc> Search]: Keyboard focus is not retaining back to the 'Search' button on pressing Esc key to close the 'Search' dialog.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Run the fast pass of accessibility insights for web.
  3. Observe the issue on 'Search' button and activate it.
  4. Now navigate on the 'Search' dialog and press Esc key to close the dialog.

Actual Result:
Keyboard focus is not retaining back to the 'Search' button on pressing Esc key to close the 'Search' dialog.
Keyboard focus is getting lost and on pressing tab keyboard focus is landing on the 'Roadmap' link in header.

Expected Result:
On pressing Esc key to close the 'Search' dialog, keyboard focus should retain back to the 'Search button'.

User Impact:
Keyboard dependent user will get impacted as user will have difficultfy inidentifying the keyboard focus and have to renavigate to content to land on 'Search' button.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/focus-order.html

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"

MAS2.4.3.keyboard.focus.is.not.retaining.back.to.the.search.edit.field.on.pressing.esc.key.mp4

[TSDoc> Search]: Ensures the contrast between foreground and background colors meets WCAG 2 AA contrast ratio thresholds for the 'Search' text.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/
Tool: Accessibility Insights for Web

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Run the fast pass of accessibility insights for web.
  3. Observe the issue on 'Search' edit field.

Actual Result:
Contrast between foreground and background colors does not meets WCAG 2 AA contrast ratio thresholds for the 'Search' text.
Luminosity ratio for the 'Search' placeholder text under 'Search' edit field is 2.666:1 which is less than 4.5:1.

Expected Result:
The contrast between foreground and background colors must meets WCAG 2 AA contrast ratio thresholds for the 'Search' text.
Luminosity ratio for the 'Search' placeholder text under 'Search' edit field should be greater than or equals to 4.5:1.

Snippet:
Search

How to fix:
Fix any of the following:
Element has insufficient color contrast of 2.66 (foreground color: #969faf, background color: #ffffff, font size: 12.0pt (16px), font weight: normal). Expected contrast ratio of 4.5:1

Notes:

  1. Same issue repro for code lines present under 'export class Statistic , get Average, IsIineTag and the code lines present under 'Consider a hypothetical input' text.
  2. Same issue repro on code line present under 'Example' heading of 'Tags' link under main navigation landmark.
  3. Same issue repro on code line present under 'Example' heading of '@returns' link under 'docs sidebar navigation landmark'.
  4. Same issue repro on #Run this ....$rush install, $npm text in 3 bullet point, $rush change in the 5 bullet point in 'Submitting a pull request link under 'docs sidebar navigation landmark'.
  5. Same issue repro on 2023 Microsoft text under footer landmark and this issue is throughout the page.

User Impact:
Person with visual disability will get impacted as user will not be able to see the text clearly and hence will not be able to interact with the content easily.

WCAG Reference Link:
https://www.w3.org/TR/WCAG21/#contrast-minimum

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"

MAS1 4 3 Luminosity ratio of Search placeholder is less than required MAS1 4 3 Luminosity ratio of search placeholder text is less than required Notes~ Contrast ratio is less than required

[TSDoc> Playground]: 'Selected' tab item such as 'DOM' is not accessible with keyboard on renavigation under 'Playground'.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/
Screen reader: Narrator

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Turn on the narrator through Ctrl+ windows+ Enter key.
  3. Navigate to the 'Playground' link and activate it.
  4. Navigate to the 'DOM'tab item and activate it.
  5. Now, renavigate on the 'DOM' tab item.
  6. Observe the issue.

Actual Result:
On renavigation, selected' tab item such as 'DOM' is not accessible with keyboard.

Expected Result:
'Selected' tab item such as 'DOM' should be accessible with keyboard on renavigation under 'Playground'.
Screen reader should announce the state information along with the position such as 'DOM Tab item selected 2 of 5'.

User Impact:
Keyboard dependent and screen reader user will get impacted as user will not not be able to renavigate back to the selected control and will not be able to make track of the content properly.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"
2   Screen reader is not announcing the disabled state nor does it announce position for the list item under ‘Direct access’ section

MAS2.1.1.Selected.tab.item.under.DOM.is.not.accessible.with.keyboard.under.playground.mp4

[TSDoc> Playground]: Visual message text is not appearing in 'Error' read only edit field when no error is found.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Navigate to the 'Playground' link through tab key and activate it.
  3. Navigate to the 'Error' through tab key.
  4. Observe the issue.

Actual Result:
On the 'Error' read only edit field, no visual message text is appearing when no error is found.

Expected Result:
Visual message text should appear on the 'Error' read only edit field when no error is found.
Such as *'No errors found'. and that should be announced by screen reader.

Observation:
With the screen reader too no information is announced to the user.

User Impact:
Keyboard dependent and screen reader user will get impacted if no message is displayed on the error read only field and hence user will get confused and will not be able to understand the purpose of the edit field.

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"

No error found visual message is not displayed

[TSDoc> Search]: Keyboard focus is not retaining back to the 'Search' button on pressing Esc key to close the 'Search' dialog.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Run the fast pass of accessibility insights for web.
  3. Observe the issue on 'Search' button and activate it.
  4. Now navigate on the 'Search' dialog and press Esc key to close the dialog.

Actual Result:
Keyboard focus is not retaining back to the 'Search' button on pressing Esc key to close the 'Search' dialog.
Keyboard focus is getting lost and on pressing tab keyboard focus is landing on the 'Roadmap' link in header.

Expected Result:
On pressing Esc key to close the 'Search' dialog, keyboard focus should retain back to the 'Search button'.

User Impact:
Keyboard dependent user will get impacted as user will have difficultfy inidentifying the keyboard focus and have to renavigate to content to land on 'Search' button.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/focus-order.html

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"

MAS2.4.3.keyboard.focus.is.not.retaining.back.to.the.search.edit.field.on.pressing.esc.key.mp4

[TSDoc> Intro]: Screen reader is not announcing any information on activating the 'Toggle word wrap' button under 'Intro'.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/
Screen reader: Narrator

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Turn on the narrator through Ctrl+ windows+ Enter key.
  3. Navigate to the 'Intro' link and activate it.
  4. Navigate to the 'Toggle word wrap' button and activate it.
  5. Observe the issue.

Actual Result:
On activating 'Toggle word wrap' button which is present under 'export class Statistics' code section, screen reader is not announcing any information.
Screen reader remains silent.

Expected Result:
Screen reader should announce the information of action performed on activating the 'Toggle word wrap' button under 'Intro'.
Screen reader should announce as 'Word text wrapped' or on renavigation screen reader announce the information as selected such as 'Toggle word wrap button selected'.

Notes:
Same issue repro on 'Toggle word Wrap' button present under '@returns'.

User Impact:
Screen reader user will get impacted as user will not get the information of action performed due to which user will get confused that whether the action is performed or not.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"

MAS1.3.1.On.activating.Toggle.word.wrap.button.screen.reader.is.not.announcing.any.information.mp4
Code snippet~ Screen reader is not announcing any information  on activating toggle word wrap

[TSDoc> Logo ]: TSDoc logo link and hamburger button is not properly visible in high contrast of desert theme.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/

Pre-requisites:
Turn on the high contrast of aquatic/desert theme through Settings> Accessibility> Contrast theme> Aquatic/Desert.

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Navigate to the 'TSDoc' logo link through tab key.
  3. Observe the issue.

Actual Result:
In high contrast of desert theme, TSDoc logo link and hamburger button is not properly visible.

Expected Result:
TSDoc logo link and hamburger button is not properly visible in high contrast of desert theme. as they are visible in normal mode.

Notes:
Issue does not repro in aquatic theme of high contrast.

User Impact:
Person with visual disability will get impacted as user will not be able to identify the content and hence will have difficulty in tracking the content.

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"
In desrt theme TSDOc is not visible properly
Issue does not repro in aquatic theme

[TSDoc> Search]: Ensure link i.e API Extractor are distinguished from surrounding text in a way that does not rely on color

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/
Tool: Accessibility Insights for Web

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Run the fast pass of accessibility insights for web.
  3. Observe the issue.

Actual Result:
API Extractor link has insufficient color contrast of 2.356:1 with the surrounding text which is less than 3:1.

Expected Result:
Ensure link i.e API Extractor are distinguished from surrounding text in a way that does not rely on color

Snippet:
API Extractor

How to fix:
Fix any of the following:
The link has insufficient color contrast of 2.35:1 with the surrounding text. (Minimum contrast is 3:1, link text: #006721, surrounding text: #1c1e21)
The link has no styling (such as underline) to distinguish it from the surrounding text

Notes:

  1. Same issue repro on 'TSDoc Playground' link, isInlineTag text, Suggest an update, Learn more, and How can I use TSDoc link.
  2. Same issue repro for 'Trimming based on related tags' link under 'Tags' link in the navigation landmark.
  3. Same issue repro on 'Rush Stack' link under 'Help' in the main navigation landamrk.
  4. Same issue repro on 'Building the projects', recommended practices, Everyday commands and Microsoft Open Source Code of Conduct link under 'Submitting a pull request' in 'Docs sidebar navigation landmark'.

User Impact:
Person with visual disability will get impacted as user will not be able to differentiate the link from the text and hence will not be able to interact with the content easily.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"

MAS1 4 1 Ensures links are distinguished from text MAS1 4 1 Luminosity ratio of the text from surrounding is less than required

[TSDoc> Search]: 'To select', 'To navigate' and 'To close' information under search dialog is not appearing on resizing the page to 400%.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/

Pre-requisites:
Change the display settings to 1280* 1024.
Resize the browser to 400%

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Navigate to the 'Search' button through tab key and activate it.
  3. Navigate to the search dialog.
  4. Observe the issue.

Actual Result:
'To select', 'To navigate' and 'To close' information under search dialog is not appearing on resizing the page to 400%.

Expected Result:
'To select', 'To navigate' and 'To close' information under search dialog should properly appear to the user on resizing the page to 400%.

Notes:

  1. Same issue repro on resizing the page to 200%.
  2. TSDOC logo link is getting overlaaped with Search button.

User Impact:
Person with visual disability will get impacted as user will not get the important information if on resizing the page, provided information on search dialog is not appearing due to which user will have difficulty in interacting with the content.

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"
On 400% To select to naviagte to close text information is not appearing under search dialog
Notes2 TSDOc logo link is getting overlapped with Search button

[TSDoc> Search]: Search dialog rectangular boundary is not visible in high contrast of aquatic/desert theme.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/

Pre-requisites:
Turn on the high contrast of aquatic/desert theme through Settings> Accessibility> Contrast theme> Aquatic/Desert.

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Navigate to the 'Search' button through tab key and activate it.
  3. Navigate to the search dialog.
  4. Observe the issue.

Actual Result:
In high contrast of aquatic/desert theme, proper search dialog rectangular boundary is not visible

Expected Result:
Search dialog rectangular boundary should be properly visible in high contrast of aquatic/desert theme as they are visible in normal mode.

Notes:

  1. Same issue repro in desert theme of high contrast.
  2. Same issue repro on the Intro page that 'docs sidebar navigation landmark boundary is not visible and this issue is repro throughout.
  3. Scroll bar is not visible which is provided under 'docs sidebar navigation landmark'.
  4. Rectangular boundary around search edit field is not visible in high contrast of aquatic/ desrt theme under search dialog.

User Impact:
Person with visual disability will get impacted as user will not be able to see the content easily and will get confused with the dialog and main section of the page if proper dialog boundary is not visible.

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"
In high contrast xsearch dialog rectangular boundary is not properly visible
4 Rectangular boundary around sesrch edit field is not properly visible
Scroll bar is not visible in high contrast

[TSDoc> Search]: Keyboard focus is not visible on 'Search' button in high contrast of aquatic/desert theme.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/

Pre-requisites:
Turn on the high contrast of aquatic/desert theme through Settings> Accessibility> Contrast theme> Aquatic/Desert.

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.

  2. Navigate to the 'Search' button through tab key

  3. Observe the issue.

Actual Result:
In high contrast of aquatic/desert theme, Keyboard focus is not visible on 'Search' button.

Expected Result:
In high contrast of aquatic/desert theme, Keyboard focus should be properly visible on 'Search' button as they are visible in normal mode.

Notes:
Same issue repro in desert theme of high contrast

User Impact:
Person with visual disability will get impacted as user will not be able to identify the keyboard focus and hence will have difficulty in tracking the content.

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"

Keyboard.focus.is.not.visible.on.search.button.in.high.contrast.of.aquatic.desert.theme.mp4
Notes~ In normal mode keyboard focus is properly visible

Translate to Chinese

Hi @octogonz
Our team really like Rush so that we want to translate it to Chinese, so I would like to consult you about something:
Firstly, Although Dinosaurs document had deployed in rush.js, however the document in this repo still marked as an experiment. So my first question is that should I translate this repo or rushjs.io-webiste.
Secondly, some questions about the form, There are too many i18n solutions, such as crowdin, which pnpm used, or just use pull request to this repo with Chinese content, or perhaps fork a repo and build ourself like webpack or angular. Which format do you expected?

Build cache docs are confusing

The section "Testing the build cache" explains how we can test the build cache after enabling it through the file build-cache.json.

It seems like the steps to see the build cache hit when building the projects are misleading. Instead of running rush rebuild --verbose I believe it should say rush build --verbose, as a "rebuild" implies that I don't want to consider whatever is in cache and instead I want to do a clean build.

Project setup: Python 3.11 not compatible with node-sass

Something (maybe Docusaurus) still depends on node-sass in this repo, and node-sass is barely supported anymore.

In particular, if you have Python 3.11 or higher installed, rush install will fail due to nodejs/node-gyp#2219.

You can do a brute force workaround on Mac:

brew install pyenv
pyenv install 3.10.1
# (ensure python3 in path is linked to the right installation)
rush install

Ideally we could eliminate node-sass in the repo to prevent this issue.

[TSDoc> Search]: Ensure link i.e API Extractor are distinguished from surrounding text in a way that does not rely on color.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/
Tool: Accessibility Insights for Web

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Run the fast pass of accessibility insights for web.
  3. Observe the issue.

Actual Result:
API Extractor link has insufficient color contrast of 2.356:1 with the surrounding text which is less than 3:1.

Expected Result:
Ensure link i.e API Extractor are distinguished from surrounding text in a way that does not rely on color

Snippet:
API Extractor

How to fix:
Fix any of the following:
The link has insufficient color contrast of 2.35:1 with the surrounding text. (Minimum contrast is 3:1, link text: #006721, surrounding text: #1c1e21)
The link has no styling (such as underline) to distinguish it from the surrounding text

Notes:

  1. Same issue repro on 'TSDoc Playground' link, isInlineTag text, Suggest an update, Learn more, and How can I use TSDoc link.
  2. Same issue repro for 'Trimming based on related tags' link under 'Tags' link in the navigation landmark.
  3. Same issue repro on 'Rush Stack' link under 'Help' in the main navigation landamrk.
  4. Same issue repro on 'Building the projects', recommended practices, Everyday commands and Microsoft Open Source Code of Conduct link under 'Submitting a pull request' in 'Docs sidebar navigation landmark'.

User Impact:
Person with visual disability will get impacted as user will not be able to differentiate the link from the text and hence will not be able to interact with the content easily.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"

MAS1 4 1 Ensures links are distinguished from text MAS1 4 1 Luminosity ratio of the text from surrounding is less than required

Header Elements Misaligned on Mobile View and Company Names in "Who's using Rush?" Section Not Visible in Dark Mode

Issue: Header Elements Misaligned on Mobile View

Problem Description

When viewing the rushjs.io website on a mobile device, the elements in the header are not properly centered. Specifically, one button is on the left, and another button is on the right, causing a misalignment issue.

Expected Behavior

The header elements should be centered horizontally on the mobile view, providing a more balanced and visually appealing layout.

Steps to Reproduce

  1. Open a web browser on a mobile device.
  2. Navigate to the rushjs.io website.
  3. Observe that the header elements, such as buttons, are not centered, with one button on the left and another on the right.

Header Not Responsive

Issue: Company Names in "Who's using Rush?" Section Not Visible in Dark Mode

Problem Description

In dark mode, the company names listed in the "Who's using Rush?" section are displayed in black, making them nearly impossible to read against the dark background.

Expected Behavior

Company names should be displayed with a legible and contrasting color in both light and dark modes to ensure accessibility and readability.

Steps to Reproduce

  1. Enable dark mode in your browser or on the website (if available).
  2. Visit the Rush documentation or relevant web page.
  3. Scroll down to the "Who's using Rush?" section.
  4. Observe that the company names are displayed in black text.

Company Names in Dark Mode

[TSDoc> Search]: Ensures the contrast between foreground and background colors meets WCAG 2 AA contrast ratio thresholds for the 'Search' text.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/
Tool: Accessibility Insights for Web

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Run the fast pass of accessibility insights for web.
  3. Observe the issue on 'Search' edit field.

Actual Result:
Contrast between foreground and background colors does not meets WCAG 2 AA contrast ratio thresholds for the 'Search' text.
Luminosity ratio for the 'Search' placeholder text under 'Search' edit field is 2.666:1 which is less than 4.5:1.

Expected Result:
The contrast between foreground and background colors must meets WCAG 2 AA contrast ratio thresholds for the 'Search' text.
Luminosity ratio for the 'Search' placeholder text under 'Search' edit field should be greater than or equals to 4.5:1.

Snippet:
Search

How to fix:
Fix any of the following:
Element has insufficient color contrast of 2.66 (foreground color: #969faf, background color: #ffffff, font size: 12.0pt (16px), font weight: normal). Expected contrast ratio of 4.5:1

Notes:

  1. Same issue repro for code lines present under 'export class Statistic , get Average, IsIineTag and the code lines present under 'Consider a hypothetical input' text.
  2. Same issue repro on code line present under 'Example' heading of 'Tags' link under main navigation landmark.
  3. Same issue repro on code line present under 'Example' heading of '@returns' link under 'docs sidebar navigation landmark'.
  4. Same issue repro on #Run this ....$rush install, $npm text in 3 bullet point, $rush change in the 5 bullet point in 'Submitting a pull request link under 'docs sidebar navigation landmark'.
  5. Same issue repro on 2023 Microsoft text under footer landmark and this issue is throughout the page.

User Impact:
Person with visual disability will get impacted as user will not be able to see the text clearly and hence will not be able to interact with the content easily.

WCAG Reference Link:
https://www.w3.org/TR/WCAG21/#contrast-minimum

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"

MAS1 4 3 Luminosity ratio of Search placeholder is less than required MAS1 4 3 Luminosity ratio of search placeholder text is less than required Notes~ Contrast ratio is less than required

[TSDoc> Search]: Ensures interactive controls such as the search suggestion present under 'Search' dialog are not nested as they are not always announced by screen readers or can cause focus problems for assistive technologies.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/
Tool: Accessibility Insights for Web

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Navigate to the 'Search' button and activate it.
  3. Navigate to Search dialog and search through keyword.
  4. Run fast pass of accessibility Insights for web.
  5. Observe the issue.

Actual Result:
Interactive controls such as the search suggestion present under 'Search' dialog are nested due to which they are not always announced by screen readers or can cause focus problems for assistive technologies.

Expected Result:
Ensures interactive controls such as the search suggestion present under 'Search' dialog are not nested as they are not always announced by screen readers or can cause focus problems for assistive technologies.

Snippet:
li class="DocSearch-Hit" id="docsearch-item-0" role="option" aria-selected="false"

How to fix:
Fix any of the following:<img width="959" alt="Ensure intercative controls are not nested"

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html

User Imapct:
Screen reader user will not be able to know the purpose as nested controls are not always announced by the screen reader.

WCAG 4 1 2 Interactive controls Ensure intercative controls are not nested

[tsdoc] Request: add examples page to tsdoc.org

Migrated from the Jekyll GitHub project https://github.com/microsoft/tsdoc.org-website/issues/24

@rossng wrote:

I would find it really useful if the tsdoc.org website had a page that just showed an example with all the common cases you would encounter while writing doc comments for an application.

For example, the C# docs do it quite well for their doc comment format.

Why? I occasionally need to write a doc comment for (say) an interface member and don't remember exactly what I'm meant to do. Does the comment start /** or /* or //? Does it need to be on the line above or inline? Do both work? Does TSDoc just use the entire comment string or do I need to prepend some kind of @ directive?

When I just want a quick answer to these questions, the TSDoc website doesn't help me much. Pretty much the only examples seem to be on the 'What is TSDoc?' page, and everything else is reference documentation (I don't know where to start looking!). Even the examples in the Playground focus near-exclusively on the syntax that goes inside a single doc comment, rather than representative examples that show how a real file with a bunch of doc comments might look.

I only write this because I can see that TSDoc is very useful. I'd like for it to be easier for people like me to get started without reading lots of documentation first.

[TSDoc> Search]: Screen reader is not announcing 'to select', 'to navigate' and 'to close' keys information which is provided on the search dialog.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/
Screen reader: Narrator

Repro Steps:

Open the above URL in edge dev browser and login with v-.
Turn on the narrator through Ctrl+ windows+ Enter key.
Navigate to the 'Search' button and activate it.
Navigate to the search box and type any character observe the issue.
Observe the issue.

Actual Result:
Screen reader is not announcing 'to select', 'to navigate' and 'to close' keys information which is provided on the search dialog.

Expected Result:
Screen reader should announce the 'to select', 'to navigate' and 'to close' keys information when focus is on the search box which is provided on the search dialog.
Screen reader should announce as 'Use Enter key to select or use up/down arrow key to navigate and Esc key to close' when search sugeestion appears to the user on typing text in search box.

User Impact:
Screen reader user will get impacted as user will not get the information which is displayed on the dialog which create difficulty in navigating or in interacting with the content.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"

MAS1.3.1.Screen.reader.is.not.announcing.the.information.of.shortcut.keys.provided.mp4

[TSDoc> Intro]: Screen reader is not announcing any information on activating the 'Toggle word wrap' button under 'Intro'.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/
Screen reader: Narrator

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Turn on the narrator through Ctrl+ windows+ Enter key.
  3. Navigate to the 'Intro' link and activate it.
  4. Navigate to the 'Toggle word wrap' button and activate it.
  5. Observe the issue.

Actual Result:
On activating 'Toggle word wrap' button which is present under 'export class Statistics' code section, screen reader is not announcing any information.
Screen reader remains silent.

Expected Result:
Screen reader should announce the information of action performed on activating the 'Toggle word wrap' button under 'Intro'.
Screen reader should announce as 'Word text wrapped' or on renavigation screen reader announce the information as selected such as 'Toggle word wrap button selected'.

Observation:
Issue repro with NVDA.

Notes:
Same issue repro on 'Toggle word Wrap' button present under '@returns'.

User Impact:
Screen reader user will get impacted as user will not get the information of action performed due to which user will get confused that whether the action is performed or not.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"

MAS1.3.1.On.activating.Toggle.word.wrap.button.screen.reader.is.not.announcing.any.information.mp4
Code snippet~ Screen reader is not announcing any information  on activating toggle word wrap

Summarized feedback/confusion about rigs

Summary

This issue summarizes feedback and confusion about rigs from our users.

Detail

Feedback and confusion:

  1. The learning curve of Rig is kind of high, the maintainer is concerned about how to educate the value of rig and how to use it correctly in their project
  2. Rigs are idea/approach, but is has to be implemented in different ways for each tool. The main documentation about rigs describes 3 different kinds of rigging

there is an NPM package @rushstack/rig-package, but it only provides the directory structure and config file resolver. Quite a lot of the implementation is retrofitted by Heft or implemented in some other way such as webpack.config.js patterns, the ESLint patch, etc.

Ideas

  1. "Using rig packages" is written too much like a reference manual. We could do more of a tutorial that's like
  • ere's the problem you will encounter in a monorepo
  • Here's the basic idea we recommend for solving it
  • Here's some examples of how you might do that manually for different tools, and the different kinds of problems you have to solve
  • By the way Heft does most of this for free, why not choose Heft? :)
  1. Compare rigs to "zero config" solutions. Both of them avoid copy+pasting settings into 400 different project folders, but rigs have some advantages:
  • the shared configuration is in data files, not program code
  • as much as possible, the config files try to conform to the standard format of the associated tool
  • if you need to maintain 20 different rig profiles, it's straightforward to represent and easy for end users to understand
  1. Basic usage first, advance usage later.
  • Basic usage: manage reusable config files like tsconfig.json, .eslintrc.js, jest.config.js in one place.
  • Advance usage: Later on, people introduced Heft and fully understand Heft, they can use Riggable config files and Riggable dependencies, it finally becomes a full-fledged Rig.

Travis CI is sadly not what it was before maybe it should be removed

I suggest that you remove the Travis CI config file as it is now an expensive product that cost 69$ per month or more...

Your documentation examples could show how to use Azure DevOps Services CI/CD or other third parties examples, some are suggested by Adam Gordon Bell in the blog link below:

January 7, 2021 · Many open-source projects are still using Travis and open-source maintainers are notoriously overworked. Time spent migrating builds is time not spent on other things. Large well-maintained projects will likely quickly transition but for many smaller projects, an abrupt change in a service they depend on is a huge challenge.
― Adam Gordon Bell https://earthly.dev/blog/migrating-from-travis/

Azure DevOps Services

When you sign up for Azure DevOps, you get the following tier of free services:

  • First five users free (Basic license)
  • Azure Pipelines:
    • One Microsoft-hosted CI/CD (one concurrent job, up to 30 hours per month)
    • One self-hosted CI/CD concurrent job
  • Azure Boards: Work item tracking and Kanban boards
  • Azure Repos: Unlimited private Git repos
  • Azure Artifacts: Two GiB free per organization
― Maybe duplicate of rushstack #3646

Project setup: browserslist outdated

I noticed while building websites for the first time in quite a while, the build would fail due to output from caniuse.

I temporarily overrode the errors with:

export BROWSERSLIST_IGNORE_OLD_DATA=1

The permanent solution is probably to periodically update the browserslist, but in a Docusaurus project it's unclear what is actually including it.

scenario: How to refer to workspace package from autoinstaller?

Let's document a "common rush scenario": how to refer to workspace package from autoinstaller.

Or, maybe, how to use a rush global command to run a tool inside the monorepo.

Or, maybe, a more generic page: how to build and use developer tools that live inside the monorepo.

This page can document strategies like:

  • Adding tools as devDependency of the consuming tools, making them part of natural build cycle.
  • Publishing tools to your private NPM registry, allowing them to be added to an autoinstaller and consumed from rush global command.

(This suggestion is based on a conversation in zulipchat.)

[TSDoc> Search]: Ensures <img> elements i.e hamburger in the header have alternate text or a role of none or presentation.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/
Tool: Accessibility Insights for Web

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Run the fast pass of accessibility insights for web.
  3. Observe the issue.

Actual Result:
elements i.e hamburger in the header does not have alternate text or a role of none or presentation defined.
Screen reader is announcing as unlabelled graphic.

Expected Result:
Ensures elements i.e hamburger in the header have alternate text or a role of none or presentation.

Snippet:

How to fix:
Fix any of the following:

  1. Element does not have an alt attribute
  2. aria-label attribute does not exist or is empty
  3. aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty
  4. Element has no title attribute
  5. Element's default semantics were not overridden with role="none" or role="presentation"

User Impact:
Screen reader user will get impacted as user will not be able to know the purpose of the image or get confused the image with informative image.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/non-text-content.html

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"
MAS1 1 1 Ensure img element must have role none or presentation

MAS1.1.1.Role.as.none.or.presentation.should.be.defined.for.the.image.mp4

[TSDoc> Search]: 'To select', 'To navigate' and 'To close' information under search dialog is not appearing on resizing the page to 400%.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/

Pre-requisites:
Change the display settings to 1280* 1024.
Resize the browser to 400%

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Navigate to the 'Search' button through tab key and activate it.
  3. Navigate to the search dialog.
  4. Observe the issue.

Actual Result:
'To select', 'To navigate' and 'To close' information under search dialog is not appearing on resizing the page to 400%.

Expected Result:
'To select', 'To navigate' and 'To close' information under search dialog should properly appear to the user on resizing the page to 400%.

Notes:

  1. Same issue repro on resizing the page to 200%.
  2. TSDOC logo link is getting overlaaped with Search button.

User Impact:
Person with visual disability will get impacted as user will not get the important information if on resizing the page, provided information on search dialog is not appearing due to which user will have difficulty in interacting with the content.

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"
On 400% To select to naviagte to close text information is not appearing under search dialog
Notes2 TSDOc logo link is getting overlapped with Search button

[TSDoc> Tags]: Table header is not defined for the 'Standardisation' and 'Syntax Kind' table present under Tags.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/
Screen reader: Narrator

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Turn on the narrator through Ctrl+ Windows+ Enter key and press caps lock + space bar key to turn on the scan mode.
  3. Navigate to the 'Tags' link through tab key and activate it.
  4. Press 'T' key to navigate on the table and then press alt+ arrow key.
  5. Observe the issue.

Actual Result:
Table header is not defined for the 'Standardisation' and 'Syntax Kind' table present under Tags.

Expected Result:
Table header should be defined for the 'Standardisation' and 'Syntax Kind' table present under Tags.

Notes:

  1. If Header is not be defined for te table then table should removed and standardisation and syntax king label sould be associated with their respective values.
  2. Same issue repro with table present under @returns in docs sidebar navigation landmark.

Notes:
Same issue repro with NVDA.

User Impact:
Screen reader user will get impacted as user will have difficulty in understanding the purpose and the content relationship within the table due to which they will have difficulty in interacting with the content.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"
MAS1 3 1 Tabel header is not defined for the table present under tags link

MAS1.3.1.Table.header.is.not.defined.under.tags.link.mp4

[TSDoc> Search]: Proper name is not defined for 'Typesense' link under search dialog.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/
Screen reader: Narrator

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Turn on the narrator through Ctrl+ windows+ Enter key.
  3. Navigate to the 'Search' button and activate it.
  4. Navigate to the 'Search by: Typesense' link through tab key under search dialog.
  5. Observe the issue.

Actual Result:
Name is not defined for the 'Typesense' link.
Screen reader is only announcing as 'Content information footer link search by'.

Expected Result:
Proper name should be announced for 'Typesense' link.
Screen reader should announce as 'Content information footer link search by Typesense'.

Notes:
Same issue repro on Playground that screen reader is not announcing any information of 'to press esc key to move out from the code sample section'.

User Impact:
Screen reader user will get impacted as user will not get the exact information conveyed to the user and hence will have difficulty in interacting with the content if purpose is not clearly announced.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"

Screen reader is not announcing descriptive information for the search by link
MAS4.1.2.Name.is.not.defined.for.typesense.link.mp4

[TSDoc> Hamburger button]: Ensures every ARIA button, link and menu item has an accessible name (.waffle_FRnN)

Test Environment:
OS Version: 24H2 (OS Build 26080.1400)
Browser: Edge Dev Version 124.0.2450.2 (Official build) dev (64-bit)
URL: https://tsdoc.org/
Screen reader: Narrator.

Repro Steps:

  1. Open the above URL in edge dev browser.
  2. Run Accessibility insights for web.
  3. Observe the issue.

Actual Result:
link and menu item does not have accessible name.

Issue: Ensures every ARIA button, link and menu item has an accessible name (aria-command-name - https://dequeuniversity.com/rules/axe/4.7/aria-command-name?application=msftAI)

Expected Result:
Ensures every ARIA button, link and menu item has an accessible name (aria-command-name - https://dequeuniversity.com/rules/axe/4.7/aria-command-name?application=msftAI)

How to fix:
Fix any of the following:
Element does not have text that is visible to screen readers.
aria-label attribute does not exist or is empty.
aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty.
Element has no title attribute.

Snippet: div role="button" class="waffle_FRnN waffleInteraction_uHqh">

User Impact:
Screen reader user will get impacted as user will not get the information of Hamburger button.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/name-role-value

Have feedback to share on Bugs ? please tag bug as “A11yRCA” and add your feedback in the comment section

Attachment:
AI tool-TSDocs-Link and menu item has an accessible name
TSDocs-Link and menu item has an accessible name

[TSDoc> Search]: Screen reader is not announcing descriptive information for the 'Search by Typesense' link under search dialog.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/
Screen reader: Narrator

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
  2. Turn on the narrator through Ctrl+ windows+ Enter key.
  3. Navigate to the 'Search' button and activate it.
  4. Navigate to the 'Search by: Typesense' link through tab key under search dialog.
  5. Observe the issue.

Actual Result:
Screen reader is not announcing descriptive information for the 'Search by Typesense' link under search dialog.
Screen reader is only announcing as 'Content information footer link search by'.

Expected Result:
Screen reader should announce the descriptive information for the 'Search by Typesense' link under search dialog.
Screen reader should announce as 'Content information footer link search by Typesense'.

Notes:
Same issue repro on Playground that screen reader is not announcing any information of 'to press esc key to move out from the code sample section'.

User Impact:
Screen reader user will get impacted as user will not get the exact information conveyed to the user and hence will have difficulty in interacting with the content if purpose is not clearly announced.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"

MAS1.3.1.Screen.reader.is.not.announcing.descriptive.information.for.the.Search.by.Typesense.link.under.search.dialog.mp4
Screen reader is not announcing descriptibve information for the search by link

[TSDoc> Intro]: In scan mode screen reader is not announcing the information of the 'TypeDoc' link which is present under the list.

Test Environment:
OS Version: 22H2 (OS Build 25370.1)
Browser: Edge Dev (Version 115.0.1866.1 (Official build) dev (64-bit))
URL: https://tsdoc.org/
Screen reader: Narrator

Repro Steps:

  1. Open the above URL in edge dev browser and login with v-.
    2.Turn on the narrator through Ctrl+ windows+ Enter key and press caps lock+ space bar key to turn on the scan mode.
  2. Navigate to the 'Intro' link and activate it.
  3. Navigate to the 'TypeDoc' link which is present under list i.e bullets' through up/down arrow key.
  4. Observe the issue.

Actual Result:
In scan mode screen reader is not announcing the information of the 'TypeDoc' link which is present under the list..
Screen reader remains silent.

Expected Result:
In scan mode screen reader should announce the information of the 'TypeDoc' link which is present under the list.

Observation:
Same issue repro with NVDA and Issue does not repro on tab mode.

Notes:

  1. Same issue repro for all the links which is present under list i.e on bullets point.
  2. Same issue repro on 'Typesense' link under 'Search' dailog

User Impact:
Screen reader user will get impacted as user will not get the information and will not be able to make track of the content and will not be able to navigate properly.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com)"

MAS1.3.1.In.scan.mode.screen.reader.is.not.announcing.the.information.of.the.links.whicj.is.present.under.bullet.section.mp4
In scan mode screen reader is not announcing links information which is present under intro Notes~ Search ~ Type sense link is not accessible in scan mode

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.