Blog

All thoughts and opinions in my blog are my own and do not represent the position of my employer.

A few links: CSS and accessibility

The blog 456 Berea Street by Roger Johansson is one of my favorite sites for useful information on web standards topics presented in a really clearly written and succinct way. He’s had some great articles recently related to the intersection of CSS and accessibility that I thought were worth sharing.

“Screen readers, list items and list-style:none“

Roger found that some screen readers won’t announce list items if list-style:none is set on the list. (They will announce the list as a whole, just not the individual list items.) This very common bit of CSS visually represses the list markers, of course, but (probably?) shouldn’t change the spoken output. Unfortunately, this falls squarely into the “good to know, but what do you want me to do about it?” camp. Just keep it in mind, and hopefully the offending screen readers will fix this behavior soon.

“Using display:table has semantic effects in some screen readers“

Same sort of thing, only with display:table. NVDA in Firefox as well as the ORCA screen reader incorrectly announce elements that you’ve set to display:table as actual, semantic tables. This might be an area where you do have other options than using display:table (as opposed to list-style:none, where there are no alternatives if you don’t want markers), so this screen reader quirk is a little more helpful to know. I wouldn’t consider this a deal-breaker, but if you can easily avoid it, I say why not? If you can’t really avoid it, I wouldn’t sweat it, but again, keep it in mind.

“Styling button elements to look like links“

This is a useful CSS snippet for when you want something to look like a link (plain text) but act like a button (initiate an action other than taking someone to a new page). Roger points out, of course, that it would be better if the design were changed so that things that act like buttons look like buttons, but this is a good option when you can’t convince those darn designers to change things! (I’m allowed to jokingly complain about designers since I am one.)

IE 7 button text redraw bug

I’ve run into an IE 7 bug that I’ve been unable to fix. I’m hoping some of you, dear readers, can help me figure it out.

I’m working on some styled buttons, created with the <button> element and some pretty basic CSS. In IE 7, if you scroll down the page so that the buttons move out of the viewport, then scroll back up to reveal them again, you’ll see lines of missing pixels drawn across the text of the buttons. It varies each time you scroll, so sometimes you won’t see any lines, and occasionally the entire text will disappear. The lines appear most often with the buttons with the largest text, but I think this is mainly just due to there being more pixels there to draw lines through, increasing the likelihood that IE 7 can screw it up. Hovering over the buttons or refreshing the page restores the text.

You can see a screenshot of the bug below, and view the bug live in IE 7 in my test page.

The buttons in IE 7 have lines drawn through their text, as if little strips of the text were erased.

(more…)

Bug fixes for removing the inner shadow on iOS inputs

A while back Trent Walton wrote about using -webkit-appearance to override the default styles of form elements in Safari on iOS devices (iPad, iPhone, and iPod Touch). Safari on iOS adds an inner shadow to the top of input text fields. It can only be overridden by setting -webkit-appearance to none or caret, or by adding a background image to the field.

Sounds like an easy fix, right? But if you didn’t read the comments on Trent’s article, you might have missed two important bugs* connected to using -webkit-appearance to remove the inner shadow:

  1. If you use caret, it removes not just the inner shadow but also the borders on desktop versions of Safari and Chrome (as well as the beta version of the WebKit-based browser on the TouchPad tablet).
  2. If you use none, it removes the inner shadow and leaves borders alone, but it disables focus styles on iPad.

In the case of the missing focus, I haven’t been able to confirm this myself; I don’t have an iPad, but the people I’ve asked to test it for me (thanks Josh!) have said the focus styles do show up, even when -webkit-appearance: none is set. Perhaps it’s a case of the version of iOS in use, perhaps the person who reported this bug in the comments to Trent’s article was simply having a problem with his individual machine, or perhaps there was something else in the CSS that was truly responsible for the problem. So it’s still not clear to me whether the second bug I listed above is really present. Do any of you iPad users have a problem seeing the red outline on focus in my test page?

If both of these bugs are truly present, they severely limit the circumstances in which -webkit-appearance can be used to remove inputs’ inner shadows. Luckily, we can use a background image instead of -webkit-appearance to remove the shadow. But what if you don’t want any background image to show? Simple—make the background image invisible. Some smart people on Stack Overflow suggested a couple ways to do just that:

  1. Tile a transparent GIF as the background image.
  2. Add a CSS3 gradient that runs from transparent white to transparent white.

I think the gradient option is ideal because it doesn’t require an extra hit to the server to retrieve the transparent GIF. And there’s no need to worry about lack of browser support, since the only browsers we want to apply the gradient are Safari on iOS.

Here’s what the CSS would look like for the gradient:

background-image:-webkit-gradient(linear, 0% 0%, 0% 100%, from(hsla(0,0%,100%,0)), to(hsla(0,0%,100%,0)));
background-image:-webkit-linear-gradient(hsla(0,0%,100%,0), hsla(0,0%,100%,0));

The first background-image declaration, using the -webkit-gradient function, is what will actually work in Safari on iOS today. The second declaration using -webkit-linear-gradient is there for future compatibility; WebKit has recently updated its gradient syntax to match the W3C specification. These syntax changes are in nightly builds and will make it into live versions of Safari and Chrome sometime soon, and you want your CSS to be prepared.

Most of this is not new information—it’s almost all in Trent’s article and comments and the Stack Overflow page. But I wanted to put it all together in one place, clearly explained, for easy reference. Hope it helps you out!

*I don’t actually know that these are true bugs. But they sure seem like bugs to me, and in any case, they certainly need some working around!

View more posts:

Archives by Category

  • Announcements (32)

    Learn what's happening in my career or industry, including information about my speaking engagements and books.

  • Articles (40)

    Informational or theoretical articles about a variety of web design topics, including CSS, HTML, accessibility, usability, and visual design.

  • Inspiration (8)

    Collections of images or links to others' design work that I find inspiring and think you will too.

  • Tutorials (5)

    Step-by-step articles that you can follow along with to learn a particular web design technique, including CSS layout and CSS3 effects.

Archives by Month