WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Hierarchical Website Navigation

for

From: Wolfgang Berndorfer
Date: Oct 10, 2018 3:15PM

Jonathan already noted performance problems of gigantic navs for those needing AT (I'm one). I'd like to add an usability issue for screen readers:

Numeric or literal indicators before a heading text to indicate hierarchy can impair UX and efficient access with screen readers. If I list up the headings of a Wikipedia page with my screen reader, typing "H" will soon lead me to "History". No chance, if my screen reader lists up "1.2 History". Similar and more problems with up / down … prefixes for links. And a lot of hacks to solve such usability issues.

By the way: "Thinking through" is a necessary, bot not sufficient method to guarant usability. Think about whom typically the webside might be. Watch an everage screen reader user and let him/her think aloud. I bet, you'll look for alternative concepts to giant navs.

Wolfgang

-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum [mailto: <EMAIL REMOVED> ] Im Auftrag von Jonathan Cohn
Gesendet: Mittwoch, 10. Oktober 2018 16:34
An: WebAIM Discussion List
Betreff: Re: [WebAIM] Hierarchical Website Navigation

This sounds very similar to what MDM and Python use for their training materials. usually complex documents like this have a panel or frame that contains a table con contents. They also contain next and previous links at both the top and bottom of the content. Of course the RFC and W3C references are generally almost as complex and they usually put everything on one page with lots of same page links for references. I do find especially in environments with slower systems and a screen reader, that having 100+ headings and intervening text all on a single page can cause slowness in AT technology response.
HTH,

Jonathan C. Cohn On Oct 10, 2018, at 10:09 AM, Meacham, Steve - FSA, Kansas City, MO < <EMAIL REMOVED> > wrote:
>
> Any advices is appreciated. Hopefully this will be useful to others besides myself. My questions are at the end, and I use level two headings break this email down. I need to do this for the US government, and I'm thinking about creating a more generic WordPress plugin that can do the same, if it is a good thing.
>
> Problem Statement
> I need to understand/validate an accessible away to provide navigation within a website that organizes its content in a four level hierarchy of. and some of the page titles are verbose. Here's a theoretical structure that could represent digital accessibility requirements: I'm using nested lists in this email just to illustrate the hierarchy. The actual pages would be associated with hyperlinks and a matching <title> and <h1> that is prefixed with a unique, sequential, dotted numeric identifier, such as "1.", "1.1.", "1.1.1.", and "1.1.1.1," to illustrate the hierarchy itself.
>
>
> * #. Technologies
> * #.#. Modules
> * #.#.#. Sections
> * #.#.#.#. Requirements
>
> Example
> Here is a tiny theoretical excerpt from such a hierarchy, with only the interesting first, second, and last pages at each level illustrated, ignoring the others using ellipses.
>
>
> * 1. Website and Web Application Accessibility Requirements
>
> * 1.1. Valid, Complete, and Correct HTML
> * 1.1.1. Page Title
> * 1.1.1.1. The page <title> MUST be present and MUST contain text.
> * 1.1.1.2. The page <title> MUST be updated when the purpose of the page changes.
> * …
> * 1.1.1.n. The page <title> SHOULD match (or be very similar to) the top heading in the main content.
> * 1.1.2. Language
> * …
> * 1.1.n. Parsing and Validity
> * …
> * 1.1.n.n. Deprecated markup SHOULD NOT be used.
> * 1.2. Mouse, Keyboard, Touch, and Voice Input
> * …
> * 1.n. Custom JavaScript/ARIA Widgets
> * 2. Web Content Accessibility Requirements
> * …
> * n. Adobe PDF Accessibility Requirements
>
> My Questions
>
> 1. Is this method of representing such information optimal, or even sufficient?
> 2. Given that there would be a tree construct to navigate this hierarchy, but it can be hidden even by visual users, is more needed? I think it is.
> 3. Would it be desirable to provide some navigation at the top of every page for essentially going up, down, forward, and back through the pages? I thought it might be.
> 4. Here's an option of what that would look like, matching the excerpt I provided in the previous section of this email. Would this be optimal or at least sufficient?
>
> Example Top-of-Page Navigation
> Note: The link destinations are bogus, so don't actually try following them.
>
>
> * 1. Next Technology ►<http://example.com/>; | Modules ▼<http://example.com/>;
> * ▲ This Technology<http://example.com/>; <https://wiki.tools.fsa.usda.gov/display/~steve.meacham/1.1.+Valid%2C+Complete%2C+and+Correct+HTML> | Next Module ►<http://example.com/>; | Sections ▼<http://example.com/>;
> * ▲ This Module<http://example.com/>; | Next Section ►<http://example.com/>; | Requirements ▼<http://example.com/>;
> * ▲ This Section<http://example.com/>; | Next Requirement ►<http://example.com/>;
> * ▲ This Section<http://example.com/>; | ◄ Previous Requirement<http://example.com/>; | Next Requirement ►<http://example.com/>;
> * …more of the same…
> * ▲ This Section<http://example.com/>; | ◄ Previous Requirement<http://example.com/>; | Next Section ►►<http://example.com/>;
> * ▲ This Module<http://example.com/>; | ◄ Previous Section<http://example.com/>; | Next Section ►<http://example.com/>; | Requirements ▼<http://example.com/>;
> * …more of the same…
> * ▲ This Module<http://example.com/>; | ◄ Previous Section<http://example.com/>; | Next Module ►►<http://example.com/>; | Requirements ▼<http://example.com/>;
> * …more of the same…
> * ▲ This Section<http://example.com/>; | ◄ Previous Requirement<http://example.com/>; | Next Module ►►<http://example.com/>;
> * ▲ This Technology<http://example.com/>; <https://wiki.tools.fsa.usda.gov/display/~steve.meacham/1.1.+Valid%2C+Complete%2C+and+Correct+HTML> | ◄ Previous Module<http://example.com/>; | Next Module ►<http://example.com/>; | Sections ▼<http://example.com/>;
> * …more of the same…
> * ▲ This Technology<http://example.com/>; <https://wiki.tools.fsa.usda.gov/display/~steve.meacham/1.1.+Valid%2C+Complete%2C+and+Correct+HTML> | ◄ Previous Module<http://example.com/>; | Next Technology ►►<http://example.com/>; | Sections ▼<http://example.com/>;
> * ◄ Previous Technology<http://example.com/>; | Next Technology ►<http://example.com/>; | Modules ▼<http://example.com/>;
> * …more of the same…
> * ◄ Previous Technology<http://example.com/>; | Modules ▼<http://example.com/>;
>
> Some things I was wondering about this approach
>
> 1. I'm using special characters to indicate that a link goes up or down or skips forward to a higher level in the hierarchy. It seems beneficial to a sighted users. For the non-visual user, should these be complimented using ARIA to add "up to," "down to," and "skip to"? If so, what if the platform doesn't support it?
> 2. Each set of these is consistently ordered, but not all types of links make sense on each page. For example, the top level doesn't have anything to go "up to," the bottom level doesn't have anything to go "down to," the first pages don't have anything that is "previous," the last pages don't have anything that is "next." Is it better to just not include such links, as above, or is it better to include placeholder text that isn't linked, or what?
> 3. I'm using consistent terminology for each link, rather than the page title the link to. This is for consistency and brevity. Using the actual destination page titles would be neither. Is this a problem?
>
> Thank you for helping to think through this problem. Again, I hope I'm not the only one who could benefit from it.
>
>
>
>
>
>
>
>
>
> This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
> > > >