Styles: advice on the positioning of the Navigation module

[ninetydegrees]

Hi,

I'm a style developer and I would like to ask the advice of screenreader users about the positioning of the Navigation module (i.e. links to Recent Entries, Reading, Archive, etc.). Several styles display this module in the 'header' area. However, its actual place in the source code varies from one style to another and I'd like to know what the optimum place is for you. Let me link you to examples:

1) Link to example 1. This is the Transmogrified style. In the source code, the navigation module is below the journal title. It's also displayed there.

2) Link to example 2. This is Modular. In the source code, the module is above the journal title and subtitles. It's also displayed there.

3) Link to example 3. This is Bases. In the source code, the module is below entries while it's displayed above entries, below the journal title and subtitles.

4) Link to example 4. This is Crossroads. In the source code, the module is in the sidebar, below the profile module by default while it's displayed at the top of the page, above the journal title and subtitles.

Would you tell me what the best place is for you, please? Suggestions and ideas about other possibilities are welcome, of course. :)

Comments

[lightgetsin]

The first two seem better to me from a screen reader navigation perspective. The third is by far the worst -- it always takes me forever to find the links I want in that style. The fourth is a smidge better. The thing that makes the first two good is that in the first I just navigate to the first heading -- journal title -- and there's everything I want. Top-of-page clutter never bothers me on dw because I can just pop down entries heading by heading very easily. Whereas bottom-of-the-page stuff below the entries is always buried somewhere that I have to find.

The second option is also doable because, even though there's no heading for navigation, the links are in an html list and I can nav by that. This doesn't help in the third or fourth examples because all of the entry links -- reply, track, etc. -- are also in lists, so it would take forever to nav by that to the links I want.

[jeshyr]

I'm glad to see that "accepted best practice" lines up with what's good for JAWS readers in this case! There are some places it sadly differs...

From a "what's considered best practice" point of view (note: I don't use a screen reader!) here are my suggestions:

I would like to see the navigation module always displayed with a header, and the same header (same text and same header level), between styles. If the style wants to specially style that header so it doesn't look like a header or hide it from non-screen-reader users using accepted methods then that's up to them, but I think it should always be there so it can be used for navigation like lightgetsin described.

The links themselves should always be displayed in a list format, again for easy navigation and semantic markup - it is a list of links after all. Lists are easy to style with CSS too, so it shouldn't be a problem for style designers.

I have no idea how styles work internally, but is the navigation module currently generated using a "display navigation module here" type of general code or is each link included separately by theme designers? If there's not a standard code for generating the navigation module perhaps this should be created and eventually all the standard styles altered to use that??

Cheers,
r

[ninetydegrees]

I would like to see the navigation module always displayed with a header, and the same header (same text and same header level)

Can you explain what you mean by that?

I have no idea how styles work internally, but is the navigation module currently generated using a "display navigation module here" type of general code or is each link included separately by theme designers

It's automatically generated. Designers don't code it manually. And it's always in a list format.

[deborah]

The navigation module (and for that matter, all of the modules, but especially the important navigation module) could always show up with, for example, <h4>Navigation</h4>. (Or whatever the appropriate header level is.) Style designers could make it vanish with the "invisible" class we put into lj_base.css, which hides text from screenreaders.

The benefit of this is that screenreader users always know what header to search for if they want to find the navigation, even if it is in the wrong place. Searching for headers and navigating that way is a standard part of all of the screenreaders I know about. For example, in JAWS, insert + f6 will bring up a list of all of the headings and the JAWS user can navigate directly to them. Navigation is eased if the user knows what heading level to be looking for.

[ninetydegrees]

Oh the way you did it with comment headers in bug 989, then.
Would that make the positioning issue pointless then? Because I was kinda hoping for more answers to my question... ;)

[deborah]

I'm going to go and advertise this community in a few relevant places, because I think we need more participants. :-)

I'm sure you saw me ask lightgetsin upstream for the answer to your specific question.

[jeshyr]

Thanks for advertising us, Deborah, I have been meaning to do so for AGES and just not got a round tuit.

*hugs*
r

[jeshyr]

Just for reference, what I meant was exactly what Deborah wrote about using >h4>Navigation>/h4> or whatever as well as the list format. :)

[deborah]

Down below in the thread, we get in a conversation about whether or not having consistent headers at the top of the navigation would make the page order not matter. Do you have an opinion on that? If the navigation bar always had a header with the same text at the same heading level, would it not matter where they were on the page?

[lightgetsin]

I think that would be helpful to some people, though not necessarily to me. It's just one of those habits of usage things -- I don't tend to use the find text string feature on webpages much, but I know some screenreader and magnification users who use it all the time.

[jadelennox]

this isn't a direct response to your question, but this comment on the webaim mailing list today seemed very relevant to this particular design issue.