Teach your password manager to look for the form named "login", instead of a specific number of tabs. We added the name attribute to the form for the specific purpose of making the site more automatable. However, the best WTDI is, at least for this site, to see what CGI parameters the form uses, and use them. We consider this a stable interface, unlike the specifics of the generated HTML.

As to using tabindex, I find tabindexes not implied by the semantics of the page or it's layout confusing and counterintuitive -- when I hit tab, I expect to go to the next link or form element. You're suggesting optimizing for login over all other use, which I think is a bad tradeoff.

I'm not going to respond to your suggestions for changing around sections.

As to using tabindex, I find tabindexes not implied by the semantics of the page or it's layout confusing and counterintuitive -- when I hit tab, I expect to go to the next link or form element.

In general, I'm in total agreement with this. However, there are situations where this, as a general rule, is not applicable. Given a form like:

Prompt 1:  [ -- default-prompt-1 -- ]  {link to help on Prompt 1}
Prompt 2:  [ -- default-prompt-2 -- ]  {link to help on Prompt 2}
Prompt 3:  [ -- default-prompt-3 -- ]  {link to help on Prompt 3}
[download]

If the tabindex on the form controls was 'n', you'd possibly want to make the tabindex on the associated help links 'n-1'.

There are other situations like this. Perhaps you want to tab through all 'required' fields first and then through any 'optional' fields.

Regards,

PN5

At least for me, as a western left-to-right, top-to-down reader, your idea of having the help come before the input would be weird, as I expect the focus to advance in the same fashion I read, that is, left-to-right, top-to-down. Breaking that order for jumping between required versus optional fields is also disorienting - if the optional fields are less important, move them downwards on the page and don't play funky games with the tab order.

The tabindex should only be used if funky CSS is used to rearrange the page layout.

Firstly, the introduction of tabindex attributes is an excellent idea; however, limiting them to the home page and citing the use of a password manager as the primary reason for adding them is, in my opinion, entirely the wrong focus.

(Note: the term 'Tab key', as used here, indicates any input to the browser which achieves tabbing functionality, e.g. 'Down Arrow' in Lynx.)

Consider why someone would want to use the Tab key to navigate this site. The reasons may be generally grouped into two broad categories:

Physically unable to use a mouse

The user may have some disability or handicap which could range from arthritis to quadriplegia.

A mouse is inappropriate for the browser being used

The user might be me testing site navigation with Lynx prior to writing this (more on that in a minute) or someone who is visually impaired and accesses this site using an audio- or tactile-based browser (e.g. a speech synthesiser or Braille interface).

Regardless of whether you agree with my categorisations, the fact remains that someone wishing to navigate this site with the Tab key wants to do just that: navigate the site not just the home page.

So, what's it like navigating the site with the Tab key. Prior to writing this I used the Lynx (text-based keyboard-driven) browser to log in and access this thread. In short, it was bloody tortuous! For instance, it requires over 20 keystrokes just to get past the links at the top of the page.

Can it be fixed? The short answer is yes but the longer answer requires another question: "What precisely needs fixing?". And that question should be answered by all Monks that have any accessibility or usability issues with this site.

Let's fully define the problem before attempting to formulate a solution!

For instance, it requires over 20 keystrokes just to get past the links at the top of the page.

I think a good (and simple) solution is to add a <a href="#content">skip navigation</a> to the top of the page, which will jump to the content. This is fairly standard practice for "accessible" websites, if you have a large navigation list (like this site).

Joost

"What should it profit a man, if he should win a flame war, yet lose his cool?"

There is an option in User Settings that turns off the the four lines of links at the top of the page. It's called "No navigation menu under title bar".

Yes, that's the standard solution to that specific issue and the one I use on my own website.

Regards,

PN5

Anyway, I guess it could be useful to have the login form in the HTML before the content instead of after it. Giving it a fixed tabindex (with the current HTML) will probably confuse users with text browsers, so I'd rather not have that.

But, what is this "password manager" you speak of?

My browser remembers the password, I only have to fill in my user name. But then, I'm the only user of this browser, so I usually just keep the login cookie.

There's more than one password manager program available that allows you to enter a login sequence that includes a user name, tabs (and other special characters), and a password, but the ones I reviewed don't let you look at the names or IDs of tags.

I keep my information in a cookie too, but I think there's still a security problem with PM that allows people to see your PM cookie, and some people log out occasionally.

I disagree with your wholesale reorganization of the various sections of the PerlMonks web site. For example, I find Perl Golf to be pertty arcane, and as a result rarely visit that section of the site. That certainly doesn't mean I think we should get rid of it.

Moving on to a food metaphor, I think of PerlMonks as a buffet with all kinds of different dishes. If I love cherries or if I have a yen for something crunchy, then that's what I help myself to. If I'm allergic to seafood, then I stay away from that.

Why get rid of those sections anyway? Is it because you think no one visits them? Or because you don't visit them? It seems to me odd that you recommend the exclusion of various sections of this community but don't explain why.