Comments (27)
Change region role from complementary to navigation
Currently, the page table of contents links are inside of a region with role complementary. The role should be navigation, not complementary. I didn't inspect, but I am assuming this might be because an aside element was used and the role was not explicity set.
from wai-aria-practices.
To enable the automatic side bar contents add the following to pages (using page specific frontmatter or global config.yml as usual)
sidebar: true
That's it.
It will:
- add an id attribute to all H2 elements based on the text
- populate the Document Contents box with links to the H2s
from wai-aria-practices.
The aria-lablel-by is specified in the template. All other criteria for this task have been met. Moving to In Review as the template will have to address the lablel.
from wai-aria-practices.
cc @mcking65 @a11ydoer did we decided what would happen to the parent "Design Pattern" link on the Example page? If we remove the miscellaneous links from the sidebar we need to either find a new home for it or remove it.
The parent design pattern is already linked to from the body content on the Example page, so that might be sufficient.
from wai-aria-practices.
RE: parent design pattern:
Would users find it helpful to have the parent Design Pattern name/title and link fairly prominent?
just fyi, for cognitive supplemental guidance and for Understanding WCAG, we have the parent in the nav pager, e.g, "Objective: Help Users Focus":
Since APG won't have the pager, we could put the parent Design Pattern in a box at the beginning of the content, similar to what we're doing with Techniques, Understanding, and Rules — e.g., "Rules Mapping":
from wai-aria-practices.
@shawna-slh wrote:
Since APG won't have the pager, we could put the parent Design Pattern in a box at the beginning of the content, similar to what we're doing with Techniques, Understanding, and Rules — e.g., "Rules Mapping":
Since we consistently have the design pattern link in the first sentence of the main content, this could end up being pretty noisy. We might want to consider another approach later, e.g., a breadcrumb nav.
For now, let's just drop the extra design pattern link.
Shawn, BTW, the "rules mapping" is inside of a complementary region inside of main. Complementary should never be inside of main. In general, it is best to avoid putting any regions inside of main. Occasional exceptions could be a search or a nav that is related to paging inside of main.
from wai-aria-practices.
Name the page contents navigation region
Currently, the rregion containing the table of contents is not named. In addition to changing the role to navigation as mentioned above, the name should be "Page Contents". Then, it will be announced as "Page Contents Navigation Region" or equivalent by most screen readers.
On this test rules page, the words "Page Contents" appear at the start of the region. However, on this APG page, the words "Table of Contents" appear.
APG should be made consistent with the template and use the words "Page Contents".
On the APG page, the "Page Contents" title is a H2, which is correct. On the rules page, it is not even marked up as a heading; that is a defect in the template or the rules page; the title "Page Contents" should be an H2.
Net, the markup should be:
<nav aria-labelledby="toc_title">
<h2 id="toc_title">Page Contents</h2>
<ul>
<li>link 1</li>
...
</ul>
</nav>
from wai-aria-practices.
Fix DOM location of page contents
On this test rules page, the page contents region is correctly loacated in the DOM just prior to and outside of the main content region.
However, on this APG page, the page contents is located inside of main.
Correct the reading order for the page contents by relocating it in the DOM so it is outside and just before main to be consistent with the template.
from wai-aria-practices.
@mcking65 you have added a deliverable to remove extra 4 links from bottom of page contents but I am not clear on what those 4 links are and in order to be able to QA the work appropriately would you please list them.
from wai-aria-practices.
@richnoah I updated the to-do list to be explicit about each of the 4 links.
from wai-aria-practices.
@shawna-slh there are two items on this issue that we need some assistance with in regards to the template:
- Setting the role of the "Page Contents" section to
- Documentation on how to set the "Page Contents" section outside of
from wai-aria-practices.
@richnoah cc: @mcking65 @s3ththompson
Let me try to clarify the situation and your request
- it looks like the side page contents box is an
aside
when it should benavigation
- great spot - that's an historical artefact - we don't use
complementary
and as Shawn pointed out elsewhere aside may be preferred. Is there still a nesting issue. If so what exactly needs to be done.
from wai-aria-practices.
it looks like the side page contents box is an aside when it should be navigation - great spot - that's an historical artifact
Looks like there are a few issues with the Page Contents sidebar. I put some in a new site-wide issue on structure and semantics
I am assuming it is best for APG to use the template sidebar: true
as is, and not do any overrides. Then, lets see if we can get the site-wide issues addressed ASAP.
We certainly welcome Pull Requests from Bocoup and others to get it done sooner.
from wai-aria-practices.
@SteveALee asked:
- we don't use
complementary
and as Shawn pointed out elsewhere aside may be preferred. Is there still a nesting issue. If so what exactly needs to be done.
There is not a nesting problem specifically related to this issue. I have observed unnamed "complementary" regions inside of main content in several places across WAI site. I will raise some separate issues related to that. Perhaps the aside element is being used inside of main and is getting mapped to complementary. If that is the case, that might be a browser bug. I'll have to look into the UA requirements and mappings related to that. If you are using aside inside of main, one way to work around such a bug would be to put role="none" on the aside.
from wai-aria-practices.
@SteveALee I might have misunderstood your question about nesting.
On the other WAI minimal template pages, there is not a nesting issue for this region.
However, in APG, we have a problem that the page contents navigation region is showing up inside of main instead of just before it.
We also have the issue that it does not have an aria-label. it should have aria-label="Page Contents". Alternatively, it could have aria-labelledby referring to the H2 that is at the start of the nav element; that h2 has content of "Page Contents" so refering to it with aria-labelledby would yield the same name as using aria-label="Page Contents".
from wai-aria-practices.
You did understand my question, thanks. I'll investigate why it would be different for APG. I suspect its due to using the tabbed navigation.
We definitely want to get ARIA usage correct for this content! :)
I had mistakenly thought the labelled-by would not be needed. Given the first rule of ARIA. After all, it's never added to the main or body to point to the H1. Or should it be? On reflexion being explicit does no harm even if markup diverges for AT. Thanks for the correction.
from wai-aria-practices.
@SteveALee when sidebar: true was implemented the attribute was not added to the H2 elements and thus the content was not added to the sidebar. Please advise.
from wai-aria-practices.
However, in APG, we have a problem that the page contents navigation region is showing up inside of main instead of just before it.
I'm confused as the sidebar is not showing what area do you mean?
when sidebar: true was implemented the attribute was not added to the H2 elements and thus the content was not added to the sidebar. Please advise.
Ah, my bad, it also needs a symblink to a plugin. I can do that for you I do not see the sidebar:true in any commit so I will create a new PR for you
from wai-aria-practices.
from wai-aria-practices.
@SteveALee yes, thank you.
from wai-aria-practices.
@SteveALee wrote:
I had mistakenly thought the labelled-by would not be needed. Given the first rule of ARIA. After all, it's never added to the main or body to point to the H1. Or should it be?
Generally, main is not named because there should never be more than one main element, the purpose of main is self-evident, and there are so many other indicators of the name of a page.
Navigation regions are fundamentally different from main even if there is only one navigation region. A name on a navigation region makes the purpose, e.g., what the user is navigating, much easier to understand.
One exception is that I often recommend naming the main region in single-page apps where the main content is a reflection of a navigation experience in one section of the page and the new content load is less evident to screen reader users. In those cases, multiple ways of ensuring the user understand which content is displayed can help the user avoid mistakes. For example, on messenger.com, we name the main "Conversation with CHAT_TITLE", e.g. "Conversation with Steve Lee". This gives one more signal of which conversation is loaded, providing one more layer of assurance that you are in the chat you think you are in.
The body element should not be named.
from wai-aria-practices.
I have reviewed the preview of #62, and all but 2 of the items are resolved in the preview:
- Providing accessible name of the navigation region -- "Page Contents"
- Positioning it in the DOM before the main element.
from wai-aria-practices.
@mcking65 these both require #72 to be merged into the launch-fixes branch and all old Contents to be deleted.
It looks like @alflennik was having problems and I'll address them now. I also now see some clashes so will merge in your branch too.
from wai-aria-practices.
Verified fixed in #62 except for the accessible name as mentioned by Rich.
from wai-aria-practices.
@mcking65 said:
Verified fixed in #62 except for the accessible name as mentioned by Rich.
Well Rich says "The aria-lablel-by is specified in the template" which I assume means is fixed and indeed the mark up I see in the launch branch is as expected
<nav class="..." arial-label-by="sidebar-header">
<h2 id="sidebar-header" class="box-h ">Page Contents</h2>
Am I missing something?
from wai-aria-practices.
In email @richnoah said
aria-label-by is governed by the template. We are not able to set the label to “Page Contents” as requested in the issue. The current aria-label-by reads “sidebar-header”
Now fixed - was a type-o in the aria-labelledby
attrib referencing the h2 element
from wai-aria-practices.
@SteveALee Alex had created a PR in wai-website-data to help with the issue of H2 ids being overwritten. Would you please review and merge if looks good to you? w3c/wai-website-data#87
from wai-aria-practices.
Related Issues (20)
- High contrast mode - link outline makes copy very hard to read HOT 2
- Provide permalinks for headings HOT 7
- `class="note"` inserts incorrect heading level HOT 2
- Generating Preview Links HOT 11
- Set up redirects for new website URLs HOT 12
- Error 404 for 14 pages after deploy of restructure HOT 3
- Broken image links on feed display page HOT 3
- 2 Grid and 2 Landmark pages lead to 404 when accessed via redirects due to casing of file names HOT 4
- [AT support sections] use existing design pattern for expandable warning box [was: affordance of expand] HOT 7
- [AT support tables] no data HOT 2
- PRs triggered by aria-practices falling out of sync
- Remove `feedDisplay` images transform HOT 2
- 404 for landmarks pattern on WAI website but not on deploy previews HOT 1
- Example pages show incorrect revision date HOT 4
- Can this be used to do live local development of patterns? HOT 4
- Update build process to use data-skipto attribute to configure skipto.js HOT 4
- Assistive Technology Support iframe element requires an accessible name HOT 3
- Date Picker Combobox Example - HTML source code example has wrong contrast ratio HOT 1
- ARIA APG search results do not contain a link
- Include updated landmark example pages and WAI site-wide search
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wai-aria-practices.