Skip to content

24 ways to impress your friends

Coding Towards Accessibility

9 Comments

Comments are ordered by helpfulness, as indicated by you. Help us pick out the gems and discourage asshattery by voting on notable comments.

Got something to add? You can leave a comment below.

Martin de Lima

Great article. Setting colors for active and focus states, keyboard navigation and ARIA roles are all very easy to implement and give great returns. I love the small nod to [Dinosaur Comics](http://qwantz.com), too!

Compass has a [link-colors](http://compass-style.org/reference/compass/utilities/links/link_colors/) mixin, though the order’s a bit weird (link, hover, active, visited, focus). Here it is with the (arguably) more common LVHAF order:

```
@mixin link-colors($normal, $visited: false, $hover: false, $active: false, $focus: false) { color: $normal; &:link { color: $normal ; } @if $visited { &:visited { color: $visited; } } @if $hover { &:hover { color: $hover; } } @if $active { &:active { color: $active; } } @if $focus { &:focus { color: $focus; } }
}
```

So you just go `a { @include link-colors( Salmon, Salmon, MistyRose, MistyRose, MistyRose ) }` and you get complete link colors.

Victor Brito

@Martin de Lima: you do not need to use Compass for that purpose: just a nested rule in Sass, like this:

bc. .my-cool-link { &:hover, &:focus, &:active { background-color: MistyRose ; }
}

By the way, unless you have to be compliant with Internet Explorer 7 or below, the @:active@ pseudo-class is not necessary.

@Stomme Poes: When you cannot change the HTML structure, it can be a great idea to apply @role=“heading”@ and @aria-level=“1”@ to make a @div@ an @h1@-like element, or apply @role=“button”@ to make a @span@ a button. But, actually, changing semantics is sometimes at your own risk. If you want to change the semantics of an element or define its ARIA semantics explicitly, before doing it, you shall read Using ARIA in HTML, more especially its recommendations table: Steve Faulkner will thank you.

Phil Rae

For those who fancy taking a look at the source code, here’s a little site I made quite a number of years ago that uses a nice bit of CSS and javascript to enhance the “tabability” of the site.

Open www.wsqo.co.uk and hit the tab key. You should now see a bold red border around the current item. Tabbing through the site should move it on to the next link. The slider on the homepage mucks it up a bit, but otherwise it’s a nice way to enhance tab navigation on the page.

Have fun!

wendee

You called the guidelines a “pig” and it’s funny cuz it’s true!

Great article and what a great gift to share. I do find it interesting that a few folks commented on starting with ARIA Landmarks and yes, though it a nice way to get introduced to ARIA it can be more complicated than it seems. And I say that because depending on the site or application you are working on, there is or can be a whole bunch of architectural planning that needs to happen to ensure consistency across the UI. Again, not all sites or apps are complex so it might be a great first step.

I do think the tablist is a great example because in most cases we are working on a more modular or widget level then we have in the past. This example is perfect for an intro too, as it is a very common and useful widget.

Great stuff. Loved it. And I am sooooo re-gifting this. ;o)

Chaals

Overall, this really is a great article. The following should be read with that in mind.

I’d suggest that adding javascript keyboard events is pretty fraught, and like @tabindex@ best avoided if possible. In the specific example, you add extra events for a @click@, but as far as I know all browsers (i.e. IE6 does) provide a native way to generate @click@ using the keyboard – whether it is enter, or space, or something else depends on the particular settings. (For the history buffs, this was what made the @activate@ event unnecessary).

Interfering with those by using Javascript will potentially cause problems. But it is unclear in this case that it solves any. And they get worse if you listen for particular keys – the “Я” key is pretty common in my office, so I guess “Z” less so.

Unfortunately, accesskey implementations are still pretty awful – most browsers forget to provide discoverability or configurability – and no modern browser has an implementation based on rel attributes.

So users accept the need to hit tab repeatedly instead of something that reaches the dizzying heights of “not terrible”, like Opera’s old setup, or what screenreaders provide.

Because at least modern screenreaders (and here’s a shameless plug for the free windows screenreader NVDA, which happens to be good) do handle various kinds of ARIA markup to help their users.

Stomme poes

@Victor
I was not asking how to change semantics, only that that would be an easier thing to show someone who hasn’t heard of ARIA than a tab panel using many hand-authored roles and states. I was not recommending that people use inappropriate HTML and cover it up with ARIA: lots of user agents and other software don’t recognise ARIA, Dragon probably being the biggest one currently.
And yes, I’m very aware of the docs. :P

Graham Armfield

A great article – and well explained. I agree with Stomme – starting with a tablist is diving into a lot of complexity to get going with ARIA.

Landmark roles help many people and can enhance every single site.

Stomme poes

Nice article, hits the main points.

I like to use landmarks to introduce ARIA, because they’re pretty simple, and then maybe something like, when you’re in some weird situation where you can’t use the right HTML like a button and so if you had to ARIA a span or div, how would you?

The tab-panel isn’t complicated, but the one time I wrote one, I vowed to only ever copy that whole chunk as a personal widget from then on, because each element sure gets a crapload of ARIA roles and states, and it can look pretty scary to a dev who hasn’t been playing around with ARIA for a while. Not the first thing I’d show, anyways :)

cheers,

Impress us

Be friendly / use Textile