CSS3 introduces the very handy columns support which is implemented in WebKit and Firefox browsers going back a fair way and degrades gracefully in all browsers that don’t support it (which appears to include IE9 sadly). The downside however is that support for the corresponding column-break property to control where column breaks are allowed to occur doesn’t appear to exist despite documentation suggesting it should. So for example1:

<div style=”column-count: 3”>
  <div class=”item”>
    <h1>Heading</h1>
    <p>Content</p>
  </div>

  <div class=”item”>
    <h1>Heading</h1>
    <p>Content</p>
  </div>
</div>

Since column hights are always equal, the two items above will be split across the three columns. To keep each item together in a column, we should be able to use column-break-inside:

div.item { column-break-inside: avoid; }

but this doesn’t appear to have any effect in current Safari or Firefox. As a work around however, we can reach for the ever useful, inline-block style:

div.item { display: inline-block; }

Since inline-block items participate in the layout around them like empty elements (e.g. img) they can’t be split across columns. Note however, that the wrapping div no longer causes a line break so the rendering would break if you had text as a direct child of the DIV as it would allow two items to potentially appear on the same line (if they both fit in full). In this case however the content is using H1 and P tags which enforce the line breaks themselves.

1 – imagine these styles have the appropriate -webkit- and -moz- prefixes, I’m using the unprefixed versions just for brevity. ↩

Many browsers include user preferences to select preferred colours for text, backgrounds and links. This is intended as an accessibility feature so that people with limited vision, dyslexia or other disabilities can choose a colour scheme that makes it easier for them to read web pages. In theory it’s a great idea. In practice however it seems to be nearly useless.

There are two “modes” these colour preferences can be used in:

1. As preferences that web sites can override.
2. As forced settings, where website specified colours and background images are completely ignored.

Preference Mode

In the first case, there are a vast number of sites which become unusable because they specify a specific background colour without also specifying a foreground colour. So if you happen to set your preferences to have light coloured text on a black background, then try to log into Google you get:

Choosing white text on a black background would make half the text on the internet disappear.

Clearly this is poorly coded websites causing accessibility programs and they should get with the program and specify foreground and background colours in pairs. Which of course makes that dialog box look like:

Much better. Except now there is no sign that I ever changed my browser preferences rendering them completely useless. So now designers have a choice between respecting browser preferences or largely designing a black and white site.

The net result is that changing your browser colour preferences will have no effect on well coded sites and break a large number of sites. So why bother?

Forced Mode

So we’re left with forcing our preferred colours on web sites. This actually gives us high contrast and is most likely very useful for people with limited visibility. However, for people with dyslexia who wanted more readable colours1 rather than just high contrast now tend to struggle because so much visual context is lost from the page. Sure, on a well coded site all the information is there, but different background colours is a really useful indicator for the various sections. That extra context and readability is now lost. That’s a disaster for someone with good vision who was trying to make the page more readable.

Compare the very well coded BBC website with preferred colours vs with forced colours.

It’s important to note that the BBC website is actually quite well coded – all the information is still available when you force the preferred colours, the designers simply have a significantly reduced ability to provide context and delineation, so inevitably the page becomes harder to read.

What to do About it?

Frankly, I have very little idea. The never properly implemented and now deprecated CSS system colours would have helped a lot in some cases. Design heavy websites would have still wanted their own colour set but web applications could have at least used them. Perhaps some way to specify a colour along with a fallback system colour could have worked. Then in the forced colour mode, the system colours would be used.

Beyond that it would be really nice if browsers were smarter about the options they provide. Instead of just a default colour setting, have a minimum contrast setting – the browser automatically increases the contrast between background and foreground colours to a specified point. Then you could combine that with a preference that text is always blue – if the website specifies black text on a white background it comes out blue text on a white background. If it’s white on black then it comes out as blue on suitably contrasting gray.

I don’t doubt that there are huge challenges here and I certainly can’t suggest the answers, but it seems like it’s about time we started putting pressure on user agents to do more to support accessibility rather than expecting website designers to do the impossible and create great designs that work with such limited accessibility tools.

1 – blue on white is actually much more readable than black on white ↩

In ARIA, there are two ways that you can attach a label to an element, aria-label and aria-labelledby. In theory, you should use aria-labelledby if the text is visually on-screen somewhere and this form is preferable. You should only use aria-label when it’s not possible to have the label visible on screen. This makes a lot of sense because generally sighted users like to be able to see the label as well and it prevents the visual and non-visual cues from getting out of sync.

However, with current support, you should always use aria-labelledby, even if you need the label to be hidden. While at least JAWS 12 and VoiceOver both read the aria-label as expected, it turns out that VoiceOver doesn’t correctly read the hierarchy if aria-label is in use. For example:

<p id="group1">Outer group</p>
<p id="item1">First item</p>
<div role="group" aria-labelledby="group1">
<a href="javascript:" role="button" aria-labelledby="item1">Item Content</a>
</div>

everything here is using aria-labelledby and VoiceOver will read the button as “First item Outer group button”. In other words, the button label, the group label and then the type of object.

However, if you change any of the elements to use aria-label, for example:

<p id="item1">First item</p>
<div role="group" aria-label="Outer group">
<a href="javascript:" role="button" aria-labelledby="item1">Item Content</a>
</div>

VoiceOver will now read the button as simple “First item button”. It doesn’t seem to matter which item uses aria-label, if it’s anywhere in the hierarchy, only the label for the button itself will be read out.

I think Otis Gospodnetić has it spot on:

IMHO, commit messages are an important piece of the communication puzzle, and I feel they are often neglected or completely not even seen that way. Commit messages (that are distributed/delivered to co-developers via email or some other mechanism) help a developer keep others in the loop. They help co-developers stay up to date mostly passively, without having to proactively look for information about recent changes.

This is especially true with distributed teams but I’ve always found it really useful for co-located teams as well. Being co-located you can provide updates verbally but it’s so much more efficient for people to keep track of the commit messages in their own time. It’s like the interruptions of IM vs the when-you’re-ready of email.

Brad Neuberg has a post up about ARIA on the iPad and some of the tricks he’s used to bend it to his will. Blogger won’t accept my OpenID to comment on the post for some reason so I’ll add some thoughts here.

tabindex

As Brad notes, you can set tabindex=”-1” to prevent an item in HTML from appearing in the tab order. Also as Brad notes, this won’t stop the VoiceOver cursor from moving to that element. It’s important to remember that the VoiceOver cursor is not linked to the keyboard focus, it’s linked to what is being read out to the user. This can be very confusing but it’s an important concept, allowing you to review parts of a document without losing the current caret position where you want to continue editing. Most screen readers seem to have this distinction between the text input focus and the screen reader cursor.

tabindex=”-1” also won’t prevent the user from moving keyboard focus to an element by means other than the tab key. For example, clicking on a textarea will move the keyboard focus to it even if it has a tabindex of -1.

aria-hidden

As a work-around to try and prevent VoiceOver from focusing an element, Brad then added aria-hidden=”true”. To his credit, Brad notes this isn’t a good situation and indeed it’s not. Now we have an element which is available to sighted users, but completely hidden to the screen reader. This is almost never what you want.

If something shouldn’t be a landmark, it probably shouldn’t be a heading element and if it shouldn’t be read by a screen reader it should generally be either not there at all or both aria-hidden=”true” and display:none; That way the element disappears for everyone, not just those using a screen reader.

I’m not quite sure what Brad was trying to achieve so I can’t really suggest the right workaround for his use case but it sounds like there may be a need to go back and get the basic semantics of the HTML right.

aria-labelledby

I’m not entirely sure what Brad’s aiming for here again but it’s a bit unusual to try and add extra audible information to a heading which isn’t available to sighted users. Normally labelledby would be used for form elements to link them with the text that describes what they’re for. My first thought here is to adjust the HTML to make it more semantic rather than trying to fix it up with ARIA. For the example HTML:

<div aria-labelledby="testH1 testH2 testDIV1">
<h1 id="testH1" tabindex="-1">
This is an H1
</h1>
<h2 id="testH2" tabindex="-1">
This is an H2
</h2>
<div id="testDIV1" tabindex="-1">
This is a div
</div>
</div>

I would say the right thing is to not have any ARIA attributes (or tabindex) at all. h1,h2 and div all default to the equivalent of tabindex=”-1” anyway and if a sighted user would see this as two separate headings and a normal paragraph, a screen ready probably should too. If it’s intended to be read as a single sentence then as a signted user, I’d appreciate it being laid out that way.

aria-label

As a side note, aria-lablledby is only one option for adding information and it’s useful if the extra information you need to present is already available in a textual form somewhere on the page. However, if the content isn’t available (for example because it’s using an icon instead of text) you can use aria-label=”The label you want” to directly specify the label text rather than referring to some other HTML element.

More Info?

It would be great to get some better background information on what’s being attempted here so that better solutions could be proposed. Right now it looks a bit like trying to use ARIA to hammer a square peg into a round hole which not surprisingly isn’t a lot of fun and doesn’t work very well.

The bottom line is that ARIA isn’t the answer to accessibility, it’s just a smattering of extra information to help out in complex cases where HTML and JavaScript are being used to create custom widgets. The first and most important tool for creating accessible web pages is still to use appropriate semantic HTML – especially for the “document” parts of a page as opposed to interactive widgets. If that foundation isn’t set, ARIA won’t save you.