-
Notifications
You must be signed in to change notification settings - Fork 152
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
Guidance in Headings for top-level should be best practice #2444
Labels
bug
Something isn't working
status: resolved
This issue has been merged into main and deployed to canary.
Comments
msft-github-bot
added
the
status: new
This issue is new and requires triage by DRI.
label
Apr 2, 2020
AhmedAbdoOrtiga
added
status: ready for triage
This issue is ready to be triaged by the Accessibility Insights team.
and removed
status: new
This issue is new and requires triage by DRI.
labels
Apr 3, 2020
This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights! |
ferBonnin
added
status: ready for work
This issue is ready to be worked on.
and removed
status: ready for triage
This issue is ready to be triaged by the Accessibility Insights team.
labels
Apr 6, 2020
Merged
7 tasks
dbjorge
pushed a commit
that referenced
this issue
Apr 14, 2020
…ssessment guidance (#2480) #### Description of changes Remove the `WCAG 1.3.1` link from headings guidance. <!-- A great PR description includes: * A high level overview (usually a sentence or two) describing what the PR changes * What is the motivation for the change? This can be as simple as "addresses issue #123" * Were there any alternative approaches you considered? What tradeoffs did you consider? * What **doesn't** the change try to do? Are there any parts that you've intentionally left out-of-scope for a later PR to handle? What are the issues/work items tracking that later work? * Is there any other context that reviewers should consider? For example, other related issues/PRs, or any particularly tricky/subtle bits of implementation that need closer-than-normal review? --> #### Pull request checklist <!-- If a checklist item is not applicable to this change, write "n/a" in the checkbox --> - [x] Addresses an existing issue: #2444 - [x] Ran `yarn fastpass` - [x] Added/updated relevant unit test(s) (and ran `yarn test`) - [x] Verified code coverage for the changes made. Check coverage report at: `<rootDir>/test-results/unit/coverage` - [x] PR title *AND* final merge commit title both start with a semantic tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See `CONTRIBUTING.md`. - [x] (UI changes only) Added screenshots/GIFs to description above - [ ] (UI changes only) Verified usability with NVDA/JAWS #### Screenshot <img width="567" alt="Screen Shot 2020-04-12 at 3 17 05 PM" src="https://user-images.githubusercontent.com/4496335/79081322-3789ac80-7cd1-11ea-9774-25888a65161a.png">
Fixed. |
lisli1
added
the
status: resolved
This issue has been merged into main and deployed to canary.
label
Apr 15, 2020
msft-github-bot
removed
the
status: ready for work
This issue is ready to be worked on.
label
Apr 15, 2020
Validated in Canary 2020.4.16.19 Thanks for the fix @Shobhit1! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bug
Something isn't working
status: resolved
This issue has been merged into main and deployed to canary.
Describe the bug
This sentence, "Use exactly one top-level heading. (WCAG 1.3.1)" is still on the "Guidance for Headings" page, but that is not a WCAG violation.
To Reproduce
Go to Assessment > Headings> Guidance >Do's
Expected behavior
the "WCAG 1.3.1" in parentheses should be replaced with "best practice"
Context (please complete the following information)
Accessibility Insights for Web
Version 2.16.0 | Powered by axe-core 3.5.1
Additional context
reported by a user
The text was updated successfully, but these errors were encountered: