-
Here’s something that’s been playing on my mind recently. What role can CSS alone play in making websites accessible? WCAG says to separate content from presentation, so the implication is that using CSS for layout, colours, fonts, etc. makes a page more accessible. But what about more specific aspects?
With HTML there are methodologies and elements we should be using to aid accessibility: label elements with form controls, scope and summary attributes in tables, meaningful alt text, and so on. But can the same be said of CSS? Are there specific approaches or styles we should be applying to aid accessibility, and what should we avoid?
It’s a tricky question, because it’s hard to take CSS in isolation. Certain HTML accessibility techniques can be applied because of CSS – marking up site navigation as a list, for example. Anyhow, here’s a jumble of thoughts:
- Having CSS in a separate file or files, thus separating presentation from content (assumming the content contains no presentational mark-up).
- Using CSS for layout (is that rife with accessibility issues in itself?)
- Including a text colour with a background colour (in case Faruk turns up with his user style sheet). Similarly, including background colours with background images.
- Relative text sizing (with ems for example). This shouldn’t be necessary, and arguably isn’t, but relative font sizing is specified within WCAG.
- Using CSS for zoom and high contrast layouts. Is this a should, a could or a maybe?
- Image replacement. They are CSS techniques, but do they aid accessibility? I’d say yes, in certain circumstances (the new TIP is particularly interesting).
- Valid CSS. If it’s important for HTML to valid, is it equally important for CSS to be valid? (For example, I’ve been known to use non-standard IE/Win filters.)
- Use different style sheets for different media – probably more theory than reality.
- Contrast and non-reliance on colour. I thought I’d mention this before someone else did, but its more a design choice and not specific to CSS.
It’s a short list thus far – have I missed out some important aspects of using CSS for (and against) accessibility?
Faruk Ates wrote:
Interesting thoughts. There’s a definitely good point you have about CSS taking care of accessibility in some cases, rather than HTML.
As for zoom layouts: Joe Clark will say it’s a should, I think, and I’m with him. We’re going to build in Zoom Layouts in -all- our customers’ websites soon, completely for free. The CMS they use will simply be upgraded to contain Zoom Layout functionality as well. It’s a very easy thing to do with CSS, and very valuable.
Two notes btw:
1. I don’t use a user style sheet, it’s a Windows color theme I have that makes the color-thing important
2. my site’s url is .net, not .com (.com only forwards) ;-)
Rich wrote:
Faruk – address corrected, but I’ll leave the user style sheet dig in there if you don’t mind (even if it is untrue). Interesting that your Windows colour theme as a similar effect.
Faruk Ates wrote:
Actually, I’ve never heard of user stylesheets being an issue here – anyone skilled enough to use a user stylesheet is probably savvy enough to know they should specify both front and background colors.
Form fields natively use the Operating System settings. Browsers tend to do that for most things, actually. It’s just more noticeable (for me) with forms because people rarely remember to specify a text color when they specify a background color that’s slightly different from white. They’ll often go “Hmm, that white is a bit too bright, I should change it to a faded brown” – yet they stop there.
And while on the subject… you’ve fixed this in the past but it seems to have resurfaced: your form fields are light grey text on almost-white backgrounds for me. Does your CSS get reset each night or something??
Matthew Pennell wrote:
It’s not actually answering the question, but I just wanted to point out that user-testing with screenreaders shows that the scope attribute for table headings is not very helpful (the heading doesn’t get read out), and you’re better off just using TH.
As for the CSS bit – I guess it depends on how you define accessibility; if you stick to the ‘for people with disabilities’ WCAG definition, your list is fairly complete; if you extend the definition to cover all users, I suppose you could argue that it helps reduce download times..?
Rich wrote:
Occasionally things may get out of sync between machines. Anyhow, the form controls now have black text specified.
Rich wrote:
Yes, Russ Weakley and Roger Hudson’s recent report on the real world interpretation of HTML table mark-up by assistive devices was extremely revealing.
Jens Meiert wrote:
The W3C partially addresses this with its Accessibility Features of CSS note.
Jim wrote:
> WCAG says to separate content from presentation, so the implication is that using CSS for layout, colours, fonts, etc. makes a page more accessible.
It’s not that you are using CSS for presentation that makes it more accessible. It’s that you can use meaningful markup instead of whatever markup happens to get the right look.
> Having CSS in a separate file or files, thus separating presentation from content
I don’t see how this helps accessibility at all. It speeds up downloading, so it helps usability, but there’s nothing inherently accessible about it.
> Image replacement. They are CSS techniques, but do they aid accessibility? Id say yes, in certain circumstances
It’s kool-aid. There is nothing wrong with plain images with alt attributes in terms of accessibility.
> If its important for HTML to valid, is it equally important for CSS to be valid?
No, it’s less important. CSS has mandatory error handling. HTML only has suggestions. Invalid CSS still has a predictable rendering; invalid HTML does not.
> anyone skilled enough to use a user stylesheet is probably savvy enough to know they should specify both front and background colors.
That’s not the problem. The problem is when an author uses only one, then it might have more specificity than a user stylesheet block that uses both. Example:
Author stylesheet:
#foo h2 {
background: white;}
User stylesheet:
h2 {
color: white; background: black;}
Pawel wrote:
I’d say here are few levels of using CSS for improving accessibility
1. Clean and semantic markup allows to use website in non-graphical devices (text browsers, aural browsers, screenreaders)
2. Additional, “more accessible” stylesheet (so called zoom layout) may help some people to use the website in graphical browsers
3. The “normal” website. The version that will be seen by 99% of users. Having the two above doesn’t mean we have an accessible website, because the regular version should be accessible as well. We may have super accessible code, great alternate zoom-stylesheet, but most people will see the website the way it was designed. The fact they don’t need to use assistive technologies or special stylesheet doesn’t mean they won’t need some help to use the website. Some basic techniques to make a website more accessible with CSS: – relative font-size – highlighting active form fields, or even active fields and their labels – using a:hover works with mouse, what about adding a:focus for those who use keyboard to navigate? – we may display accesskeys for links in a simple way: a:focus:after {attr(accesskey); } (doesn’t work in IE, may be emulated with JS)
I’m sure there’s more. My point is: when we care about accessibility we shouldn’t forget about all the users who will see our website as it was designed. The special stuff for disabled people is great, but I think sometimes we focus so much on it, to say we have built accessible website, but we can’t see the forrest for the trees – the “regular” version is not as accessible as it could be for average user.
Rich wrote:
Using CSS for presentation can inherently increase accessibility as using HTML (table layout and font styling in particular) can harm accessibility on alternative devices such as PDAs.
Cynical. Their use improves the experience in screen readers – no more speaking ‘image’ for every heading. They also provide more meaningful information for search engines. Both situations could be said to be increasing accessibility.
patrick h. lauke wrote:
that would depend on the user’s settings. i for one have not come across JAWS or other screenreaders like HAL announcing an image with proper ALT…rather, they just read out the ALT as if it was normal text.
Terrence Wood wrote:
The biggest advantage with separating content and presentation is that the html design does not have to follow the visual design.
Even though CSS based layouts are generally more accessible than table based ones, hopefully what we’ll see coming through in the next little while is design of html where there is better grouping and labeling the non-content aspects of a web page (ie. navigation, copyright disclaimers, contact info etc), rather than html written to support the visual design.
Samuel wrote:
Since you mention “alternative devices such as PDAs” I would like to claim that using different style sheet for media handheld could enhance accessibility with handheld devices. I haven’t really done any research myself but http://www.htmldog.com/ptg/archives/000056.php suggests that handheld media was pretty well supported already a year ago.
Dustin Diaz wrote:
I’d like to think that “* Use different style sheets for different media” is an excellent idea. Especially for handhelds – which seem to be getting more support quicker than speach/’read aloud’ css..
Contrasts differences is another big one. Nobody wants to see white on white. The Zoom layout could be classified as another media. I mean, technically, shouldn’t your zoom layout be an entirely new style sheet media?
Eg. media=”blind” (Yes, I know, horrible example)
Daniel wrote:
Use different style sheets for different media probably more theory than reality.
Using a different style sheet for printers to hide unnecessary data of a website (logos and menus) can be really useful. All you need to do is copy the original style sheet and add a “display:none” attribute to all content that’s not needed on a print-out. An example can be found at http://www.cbf-dogs.de
You don’t need the menu on a paper print-out, because you can’t click on the items anyways. And to save your users’ printer colors, you could also change the colors to black and white in the printer style sheet.
I’d say this is not theory, but very pratical reality.
Rich wrote:
Daniel – you’re right that print style sheets are a reality, what I was really alluding to was the less obvious media such as tv, projection, handheld and aural. With only a few exceptions there is little to no support for these.