Probably an improvement more than a bug, but something to consider for usability nonetheless. Any thoughts, Sam?

I did my little research - on single purpose login pages (such as our login/index.php) the username and password fields are focused automatically. If username is pre-filled password is selected, if not username is selected.

I am going to implement something similar on top of MDL-28158

Integrated thanks! (master and 21)

(unsetting me as tester, sorry, pressed the wrong button)

Hi everyone,

Just noticed this issue as I'm about to test it.

Auto-focused was on purposely removed from Moodle 2.0 in order to support accessibility (MDL-20410). With auto focus enabled, screen reader tends to jump directly to the focus field information and skip all the information above that. This could create confusion for vision impaired user.

Hi Rosie, just moving this to testing in progress so that no one takes it off you good spotting by the way I remember when that occurred.

Cheers
Sam

All sites I verified do autofocus on login forms, why should we not do that? The missing focus is extremely annoying for most people.

If this is a problem for screen reader software they should fix it instead.

We do not support permanent logins - this is another reason to make logging-in as easy as possible because you need to repeat it several times each day - if you store password in browser all you need is to press Enter (or type password and press enter).

My own +1 for this

We can't keep putting this in and out.

This needs to be reverted. -100

http://tracker.moodle.org/browse/MDL-20410?focusedCommentId=86406&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-86406

Can we implement this as configurable per-site behaviour? Many schools that do not have any users with screen readers would probably turn it on. Particularly, at most of the typical Czech elementary and high schools there are no visually impaired users with screen readers. Such sites would definitely benefit of this enable. We can even have a special section in the admin tree called "Accessibility" that would contain this option (among others possibly). This way, only those who really need to disable the focusing would not block this nice feature from those who want it.

p.s. To be honest, the described behaviour of screen readers really sounds as their bug but we probably can't do much of it.

Could we at least let administrators decide what is good for their users instead of letting one accessibility report decide what is good for the whole universe? (add new admin option)

just adding 2 cents after it was mentioned in the scrum: my +1 to accessibility options page. The defaults should cater to accessibility as priority though.

Raj brought up the idea of using a config option here at the office at the scrum meeting today.
Would it be overkill to do that or do you think it would be justified?
My -1 for this to go in however a setting may be the best way to keep the peace.
My first impression was that it was overkill... but peace sounds pretty good.

Dear moodle.com user,

"We can't keep putting this in and out." is not an argument that explains why every high profile site and all LMSs do the autofocus on single purpose login pages. In fact the removal was not discussed properly and should not get through in the first place. The linked issue also discusses general pages, but the login page is single purpose page which imho has different rules, I personally think that if screen reader or real user visits login page the first time it is always confusing no matter what is focused. On the subsequent visits try to imagine the screen reader starts to shout "username" or "password" - do we have any other page that does this? no, is it easy to understand that you are on the login page without all the other text being read aloud? I believe yes. We could also use longer labels on the login form to make sure the form is read like "Login username" or "Login password"...

I am going to try JAWS myself now, but I would love to hear what real people with disabilities think, our discussion here seems to be pretty clueless.

Ciao

Anyway, feel free to revert it, I will try to find some more arguments for inclusion later.

+1 for adding config option (or detect reader)

+1 to take out autofocus from other places, lol, http://tracker.moodle.org/

Peace, ciao

This has been reverted and reopened. Then re-triaged to stable. Plz, agree one solution and implement based on that.

Doesn't HTML5 have a new (non-JS) way to focus a particular form field on page-load? What do accessibility experts think of that? If you like, get sam m, or one of the other OU people, to ask our accessibility experts.

Why would they include it in HTML 5 if it was forbidden to use it everywhere. I was reading several articles about autofocus, it seems the general agreement is that is it bad to include it in every form but there are some legitimate uses on pages where the only purpose is to enter something - I personally think our login page is exactly that reasonable exception.

It would be great if we could announce that Moodle 2.2 moves from XHTML strict to HTML 5, then we would simply add the autofocus and blame the browser vendors. New browsers should give the option to turn off the HTML5 autofocus completely, the JS solution is nasty because it would be hard to detect the nasty autofocus tricks from browser code in some backwards compatible way. By the way the iOS Safari already disables setting of focus manually, so yes technically it might be possible inside browser too, but of course it does not have any keyboard navigation which makes is easier to do.

Anyway I do not want to waste my time fighting here, I am going to create a patch with setting that defaults to no focus on the login page.

Thanks for resolving this issue, Petr. I think this is the best way (don't harm accessibility by default, but allow usability to be improved with an option) to achieve the most benefit and cause the less harm.

Thanks Petr - integrated now - second time round success

Cheers
Sam

Tested on Firefox and Chrome. Works well, the autofocus obey they configuration setting. Thanks Petr!