Change Details

### Background Landmark regions are an important way people using assistive tech browse webpages. Currently most wiki pages easily have 10+ navigation regions depending on the page and wiki. These nav regions aren't always well labeled or easily understood (i.e. "Navigation navigation"), and they clutter up the DOM making it harder for users to get to the content they need (i.e the main landmark region or the contents of a menu dropdown). [[ https://jmp.sh/4AQWzW6 | Example of common nav regions ]] [[ https://jmp.sh/zvzIcyE | List of landmarks in VO/Chrome ]] [[ https://jmp.sh/hwLuftq | Example of duplicated label in menu dropdowns, unnecessary nav landmark ]] From a technical perspective, the nav element is why the menu template needs to have a heading element, which is used as an aria-label. Considering there are 4 menu types that may or may not need a label outside of the aria-label, this makes the menu CSS more complicated. The table below illustrates the heading requirements from a UI/UX perspective assuming the aria-label is no longer needed. | | Default | Portlet | Tab | Dropdown | | Requires visual label | no | yes | no | no | | Requires screenreader accessible label | no | yes | no | yes | ### Suggested behavior Many of these landmarks can be [[ https://jmp.sh/12MCkkW | combined or removed ]]. I suggest creating 3 new regions roughly corresponding to user links in the top right, the sidebar links, and the links that appear above wiki articles. Navboxs can also contribute a fair bit of clutter, as every Navbox uses a navigation role. This is less of a priority because they are located after the main content, but it could be worth looking into updating that template, and wrapping all Navboxes' under a single navigation region ### Developer notes This can be accomplished by removing the nav element from the Menu mustache template. While we could easily swap out the nav element with a div, this means that we would lose labeling for the default and tab menus. This should be acceptable considering those menus will be enclosed by new nav landmark regions that presumably would have better labels. Considering the menu types mostly all have different designs and HTML requirements. We also want to consider refactoring the Menu template to conditionally add a heading/label for only the portlet and dropdown menu types. Considering the menu types mostly all have different designs and HTML requirements, a refactor could make the behavior and styles for the menu types more explicit and easier to understand.

### Background Landmark regions are an important way people using assistive tech browse webpages. Currently most wiki pages easily have 10+ navigation regions depending on the page and wiki. These nav regions aren't always well labeled or easily understood (i.e. "Navigation navigation"), and they clutter up the DOM making it harder for users to get to the content they need (i.e the main landmark region or the contents of a menu dropdown). [[ https://jmp.sh/4AQWzW6 | Example of common nav regions ]] [[ https://jmp.sh/zvzIcyE | List of landmarks in VO/Chrome ]] [[ https://jmp.sh/hwLuftq | Example of duplicated label in menu dropdowns, unnecessary nav landmark ]] From a technical perspective, the nav element is why the menu template needs to have a heading element, which is used as an aria-label. The menu template has to handle this heading/label element for all 4 menu types, even though the UI/UX may not even require a label. This introduces extra CSS, HTML and copy. The table below illustrates the different requirements from a UI/UX perspective assuming the nav element is replaced. | | Default | Portlet | Tab | Dropdown | | Requires visual label | no | yes | no | no | | Requires screenreader accessible label | no | yes | no | yes | ### Suggested behavior Many of these landmarks can be [[ https://jmp.sh/12MCkkW | combined or removed ]]. I suggest creating 3 new regions roughly corresponding to user links in the top right, the sidebar links, and the links that appear above wiki articles. Navboxs can also contribute a fair bit of clutter, as every Navbox uses a navigation role. This is less of a priority because they are located after the main content, but it could be worth looking into updating that template, and wrapping all Navboxes' under a single navigation region ### Developer notes This can be accomplished by removing the nav element from the Menu mustache template. While we could easily swap out the nav element with a div, this means that we would lose labeling for the default and tab menus. This should be acceptable considering those menus will be enclosed by new nav landmark regions that presumably would have better labels. Considering the menu types mostly all have different designs and HTML requirements. We also want to consider refactoring the Menu template to conditionally add a heading/label for only the portlet and dropdown menu types. Considering the menu types mostly all have different designs and HTML requirements, a refactor could make the behavior and styles for the menu types more explicit and easier to understand.

### Background Landmark regions are an important way people using assistive tech browse webpages. Currently most wiki pages easily have 10+ navigation regions depending on the page and wiki. These nav regions aren't always well labeled or easily understood (i.e. "Navigation navigation"), and they clutter up the DOM making it harder for users to get to the content they need (i.e the main landmark region or the contents of a menu dropdown). [[ https://jmp.sh/4AQWzW6 | Example of common nav regions ]] [[ https://jmp.sh/zvzIcyE | List of landmarks in VO/Chrome ]] [[ https://jmp.sh/hwLuftq | Example of duplicated label in menu dropdowns, unnecessary nav landmark ]] From a technical perspective, the nav element is why the menu template needs to have a heading element, which is used as an aria-label. Considering there are 4 menu types that may or may not need a label outside of the aria-labelThe menu template has to handle this heading/label element for all 4 menu types, even though the UI/UX may not even require a label. This introduces extra CSS, this makes the menu CSS more complicatedHTML and copy. The table below illustrates the headingdifferent requirements from a UI/UX perspective assuming the aria-label is no longer needednav element is replaced. | | Default | Portlet | Tab | Dropdown | | Requires visual label | no | yes | no | no | | Requires screenreader accessible label | no | yes | no | yes | ### Suggested behavior Many of these landmarks can be [[ https://jmp.sh/12MCkkW | combined or removed ]]. I suggest creating 3 new regions roughly corresponding to user links in the top right, the sidebar links, and the links that appear above wiki articles. Navboxs can also contribute a fair bit of clutter, as every Navbox uses a navigation role. This is less of a priority because they are located after the main content, but it could be worth looking into updating that template, and wrapping all Navboxes' under a single navigation region ### Developer notes This can be accomplished by removing the nav element from the Menu mustache template. While we could easily swap out the nav element with a div, this means that we would lose labeling for the default and tab menus. This should be acceptable considering those menus will be enclosed by new nav landmark regions that presumably would have better labels. Considering the menu types mostly all have different designs and HTML requirements. We also want to consider refactoring the Menu template to conditionally add a heading/label for only the portlet and dropdown menu types. Considering the menu types mostly all have different designs and HTML requirements, a refactor could make the behavior and styles for the menu types more explicit and easier to understand.