Category Archives: CSS

CSS Strategies for resizable text

The WCAG guidelines on resizable text state that you should be able to scale text by 200%.

How to test:
In Firefox, got to View -> Zoom -> Zoom Text Only. Then when you are back in your page, zoom up to 200% by pressing Ctrl + 6 times.

Possible problems that happen when only text gets bigger:

  • Text that wraps underneath itself has too little space between the letters. You’ve set your line-heights in px.
  • using height which causes text to get cut when it overflows that height
  • Items lie on top of one another, because you’re using absolute positioning
  • text stops sitting on a particular background colour and becomes hard to see (or just looks untidy)

SCENARIO: I have an element that must be at least x pixels tall, but could grow larger if I put more text in there
SOLUTION: use min-height rather than height, remember that older IE will treat height as min-height so use your .ie6 styles or whatever you are using to set it seperately

SCENARIO: I have an element that must be no more or less than a specific height
SOLUTION: set the height in ems rather than px and the box will grow with the text resizing

SCENARIO: text is sitting on top of other text or items and is illegible
SOLUTION: rework the layout using floats or relative positioning, negative margins, or if you have fixed dimensions for your absolutely positioned item (e.g. a close icon on a lightbox), style your surrounding boxes so that their margins sit on the area where the absolutely positioned item is. At worst you may have to use a bit of JS to refine the position (e.g. you need to align something to the bottom of another element) but that is mixing styling rules with behaviour rules.

SCENARIO: my text no longer sits on a coloured background, I’ve run out of background image
SOLUTION: rebuild so that the background surrounds the content section of your box, which has a background color. The background adjusts as the size of the content grows and shrinks because it sits around it rather than under it
LEAST DESIRABLE SOLUTION: wrap your text in an element that gets given a background color

SCENARIO: there’s no longer enough space between the lines of text
SOLUTION: don’t set line-height in pixels, set it in ems, and make less use of them because as you use relative units, you’ll find that they are a pain to maintain when they start getting inherited.

jQuery UI sortable incorrectly positioned on drag when page is scrolled

While this issue is a bit odd, there’s not much in the way of information online and I suspect it will become more common as people start adding support for smaller screens and mobiles to their sites.

Here was our problem:
When dragging a sortable element, positioning was fine unless you were scrolled down the page a little.

After some trial and error, we found it was created by a combination of body{offset-x: hidden;} and position:relative on one of the parent elements of the sortable widget.

Now we don’t want to go removing things from other people’s pages to fix our work, because it will almost certainly break something else (these are templates, so the risk is high and regression testing a big task). The solution was to put offset-x: auto on the same element that gets scrollable applied to it.

This is due to get fixed in jQuery UI 2 as they rewrite the sortable plugin.

Interface Developer’s quality checklist

Towards the end of a project or sprint, time to delivery can sometimes get crushed due to any number of reasons (late wireframe or design delivery, too many iterations, staff illness, contractors leaving, underestimation, overdelivering, changing business needs, etc.), and sadly it is usually testing time that cops it.

This checklist should help you check you’ve got your main bases covered.

Tools you’ll need

Checklist

  1. Having stable, valid code will save you a lot of debugging pain.  If you know your code is sound, then it is most likely a browser fault that is the cause of any further bugs from here onwards
    1. Run the W3C HTML validator on all pages and correct
    2. Run the W3C CSS validator on all pages and correct
    3. Run the WAI tool on all pages.
    4. Run your JavaScript code through JSLint
    5. If you are hoping to have good coverage on mobiles, run mobileOK on your pages
  2. Check the static text content for spelling and grammar.  Mistakes here will just make you look stupid and unprofessional.
  3. Check you’ve done a full run-through of the site in each supported browser.  You do have an agreed browser matrix don’t you?
  4. View your site without CSS, can you still read everything?
  5. Open up each template in a new tab and run through them using CTRL+Tab to check your layouts are all the same – do the edges of the main layout boxes sit at the same position on each page or do they jump a few pixels? Is the main heading at the same position (presuming your design intends that)?
  6. Run through all pages at 1024×768 resolution (or 800×600 if you are required to support it), do you have to scroll horizontally?
  7. Try using your site without JavaScript.   If you can’t then non-JS users will not be able to use your site and search bots will not be able to index all your content
  8. Have you remembered your print stylesheet? Print preview your pages and actually print the most likely to be printed (e.g. an article template).  Sometimes the preview lies.
  9. If you are using flash, check your non-flash fall-back works.  You do have a fall-back right?
  10. If you are using embedded media, check there is a fall-back for those without it and a link to the vendor site to download the plugin.
  11. If you have static links in the site, run a linkchecker.  I’ve used Xenu in the past which is fairly good, and free.
  12. Run your pages through YSlow to find any major issues
  13. If you are using XMLHttpRequest (often referred to as AJAX), test what happens when the server returns a failure (e.g. a 404 or 500 rather than 200 OK)
  14. Accessibility checklist (this isn’t a definitive list, if for example your navigation is inconsistent between pages then you’ve a problem that requires the team going back to the drawing board to solve)
    1. Your content is in a sensible order in the HTML.  If you are not sure, looking at the page with CSS off will help you decide.
      • e.g. you do not break up your main content paragraphs to line up your right hand promo boxes
    2. Go through a few pages with a screenreader and keyboard.
      • Can you get to all your links and form fields without the mouse?
      • Can you hear all your content?
      • Is hidden content still ‘perceivable’?  If you are hiding with display none or visibility hidden, screenreaders will ignore that content, but if you use position absolute with left being a large negative number, it will still get read out to the user.
    3. Test all your interactive features (e.g. accordions or sliders) with a keyboard, also is the screenreader able to read the information in them? (see my previous post about focus)
    4. Page sections are marked out with headings
    5. Headings do not skip levels.  This should be picked up in the HTML validation.
    6. Have a ‘skip to content’ link at the top of your page
    7. You can pause any animation or movement that is on by default
    8. All forms have a submit button
      • that especially includes select field (dropdown) navigation, it should never be executed from the onchange or onselect events
    9. Text can be resized in all browsers, IE6 does it differently so be sure to test if you support it
    10. All form fields have explicit labels (i.e. you use the for attribute to refer to the field’s ID rather than wrapping the field inside the label element)
    11. Missing alt attributes is a common mistake, but will be picked up in your HTML validation
    12. Foreground and background colours have sufficient contrast
    13. Testing for seizure-causing animation is difficult, but the safest course of action is not to flash anything more than 3 times in 1 second.
    14. Image maps have their links duplicated underneath as a list
    15. Any static links have sensible link text that indicates where the link will go on its own without the rest of the paragraph text around it.
    16. Any linked images have sensible alt text that indicates on its own where the link will go
    17. Specify what language the page is in.  The HTML validator will pick it up if it is missing.
    18. Tables of data have a summary and scope for each column and each row is defined

Get some focus: outline

When a link or button has focus, there is usually a visual indicator such as a dotted or coloured line around the element.

The CSS property is called outline.

Some designers/developers find the outline ugly and remove it using outline: none. Some reset CSS files also include this by default, with the optimistic expectation that you will set your own.

Eric Meyer says that he’s removed the outline “so that you remember to define your own”, however I’ve noticed that this is the exception rather than the rule.  I’ve a great deal of admiration for Eric Meyer, his work on CSS has improved many a developer including me, but on this issue I have to disagree.  A quick search on google code search shows just how regularly it doesn’t get done.

If you really wanted people to remember to redefine their own outline styles, you’d make it 6px solid red.

Removing the outline makes a page inaccessible because a keyboard-based user has no indication of what has focus or where their cursor is.  They have absolutely no idea of where they will end up if they press the enter key and absolutely no idea of where they are in the page order.

Visible focus in now an AA level accessibility guideline: http://tibor.w3.org/TR/WCAG20/#navigation-mechanisms 2.4.7

So please don’t remove the outline, and if you come across

a{
...
outline: 0;
...
}

in your CSS, remove this and set the outline to 0 on the hover and active states  or reset it using the :focus pseudo-class:

:focus {outline: 1px dotted;} /* or similar */

The colour of the outline should be inherited from the link’s default colour if you don’t specify one.

UPDATE: Patrick Lauke also has an interest in this and has set up his own CSS outlines test page. Suppressing the outline on the :active pseudoclass seems to be the most elegant solution to stay accessible while avoiding the outline for mouse users.

UPDATE 2: Patrick has since discovered a flash of outline occurs on links to external pages so the best suppression technique is:

a:hover, a:active { outline: none; }