I will drop you a line separately about the issues we have here. I am planning a meeting with our tech security/firewall bods to discuss the matter and learn more about it so once I’ve done that I’ll get back in touch with you.

I want to point out that Ma.gnolia does have a lot going for it in terms of accessibility. We made it a priority when we contracted Happy Cog for the overall design, and more than once opted to forego the flashy for the more widely accessible. I think our hearts are in the right place, even if the signin page isn’t meeting expectations. Moreover, we’re willing to learn and change based on feedback like this. We talk a lot with the community that’s building up around Ma.gnolia, and they’ve been the drivers of almost every fix and tweak and new feature that we’ve worked on in the last few months.

To put a little substance behind that statement, we’ve already made one change to fix the most important problem identified here, which was that Ian was unable to sign in from behind his workplace firewall. The change (which will be deployed within a few days) will only modify the submit button if javascript is enabled. I think we’ll be able to get that empty field checking in there, too, Rory.

I’ve also asked the development team about providing appropriate warnings and substitute behavior where possible. Why do we change the submit button at all? Quite simply for consistency with the rest of the site. This is the front door to members, and it should look like it. Being accessible shouldn’t be contradictory with that goal.

I’d like to build on some of the advice in the post and the comments to make deeper changes and to refine our working strategy for future development. Ian, would it be alright for me to get in touch by email so we can go over some approaches that would work better for people who might have been frustrated like yourself? If anyone else here would like to contribute to that discussion, drop a line to me personally [email protected] and I’ll get you into any conversation that comes of this. Thanks for the comments, all. It’s the kind of discussion that we definitely learn from.

I didn’t get that sense. I think it means, “It isn’t worth sacrificing accesibility for something that’s just bling bling.” Or as a user’s internal dialogue might sound, “Wow, what a fancy pretty sexy login page! Beautiful! Too bad I can’t use it from behind my firewall. If only they just made it functional instead of sticking all that ‘design’ into it…”

At the same time however, in order to build something exciting, it’s sometimes necessary to require a certain level of compliance with platforms or whatever. Want to use Windows Update? You need to have Windows installed. Want to run OSX? You better have a recent Mac. Want to use Gmail? All that AJAX means you need javascript enabled and well-supported. And if you build something that excludes a certain portion of potential users, say with screen readers, well, maybe it won’t matter if those vision impaired folks wouldn’t be able to play those Flash games anyway. They don’t use the Net for that sort of thing. Deaf users don’t visit iTunes very often I imagine, either.

@William: your explanation still doesn’t take into account why you’ve unnecessarily replaced a built-in method for form submission with an onclick handler on a link. The only reason I could think of would be to provide visual consistency across the site via using an A element rather than an INPUT (which doesn’t allow for :hover styling on IE), but really, this could have been solved any number of other (better) ways.

Using the Hijax approach (def. in comment #4), you could start with a base form, then use external JS to switch out the submit button for your link method. You can be sure that a) the replacement button appears with all the JS dependencies it needs; or b) there will be no switch and the submit button works as before.