Answer My Query

Sometimes designs contain button styling that is difficult to create with CSS alone. The “official” way of dealing with this is to either use an image button (<input type="image" src="button.png" alt="Ok" />) or put the image in a button element (<button><img src="button.png" alt="Ok" /></button>).

However if the graphic you want to show instead of the button is part of a sprite image, or if you want to display a different image when the button is hovered over or receives focus, that won’t work. In these cases it can be tempting to just use a background image and move any text the button contains out of the way by positioning it off-screen or applying a bit of text-indent. Or even worse, use no text content at all. Using no text content at all is obviously no good to anyone who can’t see the image, like screen reader users. And hiding the text causes problems if the image can’t be displayed.

Much of this is covered by Nicholas C. Zakas in Making accessible icon buttons, and I thought I’d talk a bit more about a technique he mentions that I use in these situations – the transparent one pixel image.

Read full post

Posted in Accessibility, Browsers, CSS.

Copyright © Roger Johansson

When you want to make an element on a web page clickable in order to trigger a JavaScript function, the best option is to use an element that has native support for keyboard interaction. In most cases a button (either <input type="button" /> or <button type="button"></button>) is the most appropriate element. It lets everybody trigger your function, whether they use a mouse or not.

Unfortunately, many (maybe even most) developers do not use the correct HTML elements for this. Instead they often use elements that have no native support for keyboard interaction, like span, div or li. A slightly better choice is the a element since it can receive keyboard focus as long as it has a non-empty href attribute (i.e. <a href="#">Click me</a>). But it isn’t really a link anymore since it acts like a button and doesn’t lead anywhere.

What do I suggest then? There are two options:

1. Use real buttons and style them so they look the way you need them to look.
2. If you simply cannot or will not use real buttons, make sure your fake buttons can be focused and activated without using a mouse.

Read full post

Posted in Accessibility, JavaScript.

Copyright © Roger Johansson

As I have noted in a couple of blog posts recently, there are some cases when CSS has quite unexpected results in screen readers (or the way web browsers create the accessibility information they hand over to screen readers). If you haven’t read them, the posts are Screen readers, list items and list-style:none and Using display:table has semantic effects in some screen readers.

Here are a few examples:

• Using display:table on non-table elements to get the visual layout characteristics of an HTML table without actually using one may cause screen readers to act as if there was a real table
• Using display:block or float on table-related elements may cause screen readers to treat the table as a layout table and ignore its semantics or report an incorrect data structure
• Using list-style:none to visually remove bullets or numbers from list items may cause screen readers to ignore them too, basically treating list items as paragraphs of text

Read full post

Posted in Accessibility, CSS.

Copyright © Roger Johansson

Back in the day you used to be able to view source on a web page to see the markup used to create it. These days, on many sites, a large portion of the markup is not visible when you view source because it is inserted by JavaScript functions.

That isn't necessarily a problem provided that you use progressive enhancement and unobtrusive JavaScript. If you follow those principles, content and basic functionality will still be there when scripting is unavailable. Many of us understand that. But one thing I’ve noticed is that some developers forget to consider semantics or accessibility in the markup they use JavaScript to insert.

Read full post

Posted in (X)HTML, Accessibility, JavaScript.

Copyright © Roger Johansson

I’ve always been wary of styling form elements too much. Possible usability and accessibility issues, browser quirks, and the fact that the CSS specification does not define form control styling are the main reasons.

With that said, sometimes you have to do things you don’t really want to. Like styling select elements, which I’ve recently had to find a way to do. There are quite a few workarounds for doing this out there. However, most of the ones I looked at replace the select element with a bunch of links which changes semantics and behaviour a bit too much for my tastes. I couldn’t find any implementation that I was completely happy with, so I took the best one I could find and tweaked it.

Read full post

Posted in Accessibility, CSS, JavaScript.

Copyright © Roger Johansson