JavaWoman considers…

Maybe it's hyperbole, I really don't know. But it's not funny.

With an inaccessible form like this Opera is sending a clear message that people who need accessible software and an accessible web need not be interested in Dragonfly and "upcoming Opera products".

Now where is chaals when we need him?

Forever the nomad, huh? Thanks for looking, chaals!

@dstorey: Thanks, mr. Chief Web Opener!

(Not at home and "borrowing" someone's WIFI connection - not sure how long this will last...)

David, wow, that's fast action! I'm very pleased to see Opera are taking this so seriously.

I fully understand the need for some spam protection, but the problem with a graphical Captcha is that it's essentially inaccessible. So if you can replace that with the module used in My Opera that will be great.

I had a quick look at the page's new markup and it's greatly improved. You even fixed the headings (which were a minor problem I didn't even point out), all input fields have a label, and the image button has a correct alt attribute.

But we're not quite there yet. A few use cases:

• Using a text-only browser (no CSS, no JavaScript): no problem, each field has a label prompt, and the graphical Submit button should be usable because of the alt text. Great.


• Using a graphical browser with a screen-reader, using CSS but JavaScript disabled: again no problem. The stylesheet uses just display: block; for all labels, so each field will be announced with the prompt.


• Using a graphical browser with a screen-reader, with both CSS and JavaScript enabled: this is no longer unusual as modern screen-readers are better able to handle JavaScript, and since a screen reader essentially runs "on top of" what's displayed on-screen, that will include everything JavaScript has done.
  
  Looking at the visual layout, I see no prompts (labels), and looking at the Dragonfly.js script, it's easy to see why. What it does is it takes the text of each label and copies it as "value" into the entry field it belongs to (nice touch). But it also hides the label itself with labels{i}.style.display='none'; (I had to replace square brackets with braces to get around My Opera's parser here ) - and that is a problem: the JavaScript runs on page load, so once the page is fully rendered, there are no labels anymore.

The problem with in last case is that display: none removes the element it's applied to completely from the text stream, and current screen-readers are standards-compliant enough that they implement this correctly now. And it does not matter whether this styling is applied via CSS or JavaScript. As a result, for everyone using a modern screen-reader, having both CSS and JavaScript enabled, there still are no labels for any of the input fields.

What you really want to do is move the labels visually out of the way, without making them inaccessible. I think the form would be a little more usable with simple visible prompts, but if you really want to have the esthetics as originally designed here, you can accomplish that without making it inaccessible. Just move the labels off-screen with absolute positioning: that way they won't be visible but they will still "exist" in the text stream and thus be read by a screen-reader.

Have a look for instance at this article: Accessible Dynamic Links - it's not about form prompts, obviously, but explains quite well the difference between hiding something with display:none and making it invisible by moving it off-screen, and when each is useful: sometimes you do want to make elements disappear completely, and that's what display:none is good for, but sometimes you merely want them to make them visually disappear but keep them (literally) still accessible, and that's what moving them off-screen is good for.

You might also want to read my post Skipping along where I also pointed out that it's still a wide-spread misunderstanding that elements "hidden" with display:none are still available for people who use a screen-reader - but they are simply "not there". (It was true for older versions of screen-readers, which are still in use, but all current versions are standards compliant in this.)

Still, structurally the page code has been greatly improved, and the JavaScript only needs a small tweak.

Note: I haven't looked at the contrast yet - I don't have all my tools available yet on the new MacBook I'm using now, but I'll see what I can do tomorrow, otherwise I'll look when I'm back in Amsterdam.

(Now, let's hope my borrowed Wifi connection plays nicely and lets me post this!)

David: line-height might work, too; I'm not entirely sure that will work with all browsers though (I could try to find a reference for that when I'm back in Amsterdam tomorrow).

Meanwhile I've installed (portable) Firefox on my MacBook with the Firefox Accessibility Extension and the WAVE toolbar. The latter showed me what I'd missed yesterday just looking at the code: while the HTML code structurally makes sense with an H1 heading, that is also made to disappear with a display: none in the stylesheet. Same fix: more it off-screen instead.

BTW, just in case: both display: none and visibility: hidden should be avoided for those elements that should disappear from view only but should remain present and accessible in the text flow.

Next week is soon enough.

David: I remembered something about problems with line-height, not exactly what it was.

What I found (back) is that support for it is still incomplete in IE6 and IE7, but the problem is mainly with a combination of line-height and replaced content (images) in the same element, also mentioned in the matrix on webdevout.net.

That said, in your blog the actual text of H1 heading and subtitle do disappear in IE6 (don't have IE7 to test with), but the subtitle image overlaps most of the H1 image.

(That's probably still better than my tweaked top bar which disappears entirely in IE6. Although the links actually in the top bar still work even though they can't be seen, it seems the "Skip navigation" in my version is inoperable in IE6. )

Anyway, best to check resultant layout in IE6 and IE7 if you're using line-height + height to make text disappear from view. Or use one of the other techniques to make text disappear from view (absolute positioning, padding, text-indent).

I'm not a big company either, so I'm taking some leeway with styling here, but having an accessible blog is important for my "branding" anyway. IE6 usage currently shows as only 1% in my statistics, but I'd better ask someone to have a look with IE7 until I'll have that installed on my MacBook.

But Opera is a big (or biggish) company and my impression is it considers its branding quite important.

Glad to hear you're working on it — please let me know when I should have another look!

Hmm... It seems my "just in case" above about usage of display: none and visibility: hidden was spot-on but has been overlooked anyway!

CSS for the heading now reads:

h1 {
visibility: hidden;
position: absolute;
}

which still makes it disappear completely instead of moving it off-screen so it's still available...

Replacing one problem with another is not a solution — I hope that's another April Fools' day joke?

Don’t hide it, move it!

More than one week after Opera's first fast action to rewrite the HTML (or underlying XML) for the page, let’s see where we stand now:

• The HTML is now nicely structured, semantic markup. With a proper h1 heading at the top, and label tags for all input fields. Very good.
• The text color of the input fields is slightly darker, providing a little more contrast. But I think the contrast is still too low, and so does the check done with the Firefox Accessibility Extension - they want to see a 1:3 contrast. I'm not sure 1:3 is actually necessary, but it sure could use a little more punch. So, points for good intention, but not quite there yet.
• That new h1 header is promptly made to disappear again with the stylesheet. Not good. Don’t hide it, move it!
• Each of the label tags is used to produce an initial value for each of the input fields, and is then equally promptly made to disappear, this time with styling applied by JavaScript. Not good either. Don’t hide it, move it!
• We still have the same inaccessible visual CAPTCHA. I realize it may take longer to fix than the rest of the form, so that’s just here as a reminder; but what we have now is still not good.
• Result: in spite of the better HTML code, the page, and the form on it, is just as inaccessible as it was to begin with.

Maybe I’m impatient (OK, I am getting impatient), but it looks like — after an initial fast action to change the HTML showing good intentions — nobody’s actually been doing anything for a whole week. So what message is that sending now?

Maybe two quotes from right here on My Opera can help a little bit to prod you into action again:

by the way, MyOpera is almost, without exception, EXCELLENT when it comes to accessible slash useable forms; very clear labels are an unfortunate oddity on the web...
(by oedipus)

I also found the security code box on the sign up was and is a nightmare to see.
(by talatkm)

So, let’s please make clear labels a little less of an oddity (hidden labels aren't clear!), and let’s replace that nightmare by an accessible version!

Not necessarily all at the same time, but it would be great if we could see something is actually being done after that first flurry of activity at the end of last month.

Good! We've got a header now:

h1 {
position: absolute;
left:-999em;
}

Labels next?

Thanks for the update, David. I do trust this page will be fixed. But my point is this: unlike the Opera Dragonfly site, this site is already out there and clearly intended to draw attention. So — excuse the (unintended) pun — I would suggest that merely saying this has priority is not quite enough: visibility matters.

I also think this case is a nice illustration of the fact that it is far more cost-effective to design with accessibility in mind right from the start, rather than to have to go back and repair what's broken when it's already released. With the Opera Dragonfly site you still have that option (or at least relatively so, since it's not out there yet). With this site no more, and never mind that it's only a single page: it is your shop window now.

I'm planning to sign up for that newsletter as soon the page is fixed.

Great, progress! And I like the classname "yank".

While we're wating for the visual CAPTCHA to be replaced by the accessible variant already used in My Opera, here's an update on the color contrast.

The Firefox Accessibility Extension was complaining that the contrast (the green color used for text inside the white form fields) was not sufficient, but it doesn't make it very clear what, exactly, it is measuring.

Juicy Studio has an online Colour Contrast Analyser that not only clearly explains the colour contrast algorithm suggested for Guideline 2.2 of the Web Content Accessibility Guidelines 1.0 but implements it as well. All you need to do is plug in forground and background color codes and it will tell you how that performs.

Visually, I thought the color contrast in the entry fields was borderline, and when I plugged in the colors used (background #fff and foreground #72a530), I found that confirmed: the brightness difference is 118, just below the threshold of 125, while the color difference is 438, below the threshold of 500.

Just a little bump in contrast should do the trick then; use the Colour Contrast Analyser to see how you're doing before plugging it into the page.