BlogmyQuery – BMQ

Showing whether a link on a web page has been visited or not can be very useful. One example that many will be familiar with is how it helps you know which links you have already followed from a Google search results page – links to pages you have already visited are a different colour than the other links.

Changing only the colour can be a bit subtle though, especially for people with colour vision deficiency. Depending on which colours are used to differentiate between visited and unvisited links it can be hard to tell them apart. To make the difference more obvious, there are a number of techniques involving background images, generated content (like the one I describe in Check marking visited links), and other CSS properties. However, if you’ve been using any similar tricks to style visited links, it’s time to forget about those and start relying on colour alone.

Read full post

Posted in Browsers, CSS.

Copyright © Roger Johansson

When adapting a layout for different viewport widths (a.k.a. responsive design) or media (like print), it’s common to reset any float and width values on major layout blocks to linearise their display.

Unfloating a floated element is as simple as specifying float:none. Width doesn’t seem to be quite as straightforward – lately I’ve come across several cases where people use width:100% to undo explicitly specified widths when they should be using width:auto instead. So here’s a brief explanation of the difference.

Read full post

Posted in CSS, Quick Tips.

Copyright © Roger Johansson

I just recently ran into an issue when styling buttons that had me pulling my hair for a while. I had my buttons looking the way they were supposed to look in desktop browsers, but when I went to have a look in Safari for iOS, much of my CSS wasn’t applied.

This was pretty puzzling as I couldn’t remember having any problems with buttons in Safari for iOS before. After taking a closer look at the CSS I was using for these particular buttons and the CSS I had used previously, I managed to find out what made the difference.

Read full post

Posted in CSS.

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