Importance of valid CSS to accessibilty?
I've always been sympathetic to the view that WAI checkpoint 3.2 refers as much to CSS as it does to markup, even though official examples and references rarely refer to CSS in the techniques.
| Quote: |
| Guideline 3. Use markup and style sheets and do so properly.
… 3.2 Create documents that validate to published formal grammars. [Priority 2] For example, include a document type declaration at the beginning of a document that refers to a published DTD (e.g., the strict HTML 4.0 DTD). Techniques for checkpoint 3.2 |
In addition to the checkpoint, the color warnings present in the CSS validation report adds further weight to the view that CSS has an impact on accessibility.
I've had someone state that there are presently no issues with using invalid CSS that impact negatively on accessibility.
Whilst I generally respect that person's views, it simply doesn't ring true to my ears.
This sounds like a tentative truth at best and one which lacks the forward compatibility that valid code is supposed to help foster.
So, basically I'm looking for some form of clarification, both regarding the impact invalid CSS can have on accessibility now as well as in the foreseeable future.
[edit]
Besides plain mistakes in the CSS, I'm also thinking about purposeful invalidations, such as hacks used to target specific browsers - specifically those hacks which use invalid grammar, such as the underscore hack used to target IE/Win.
Additionally, fwiw, I'm not trying to prove my position. I'm honestly looking for info from a group who have a more extensive understanding of issues and potential issues than either myself or, by my reckoning, the other chappy.
[/edit]
tia
Last edited by Bill Posters on 12 Oct 2005 10:48 am; edited 2 times in total
Share: 
The only real case I can think of is a recent site which I audited which had invalid css. As a result the top nav, which was fine in IE, didn't work at all in Firefox.
Share:
Plain mistakes like having white text on a white background.
Well, hopefully when browser X fixes it's bugs the invalid CSS hacks will make a mess of the page.
};-) http://www.xhtmlcoder.com/
WVYFC chose the Yorkshire Air Ambulance as the main charity to fund raise for in 2006
Share:
| Daz wrote: |
| The only real case I can think of is a recent site which I audited which had invalid css. As a result the top nav, which was fine in IE, didn't work at all in Firefox. |
Can you recall any details?
-
I've distilled my view down to the notion that, when forced to target specific browsers, I'd rather use valid CSS to exploit differences in standards support rather than use invalid CSS to exploit difference in browsers' tolerance to non-compliant code.
The former occurs to me to be a more stable, predictable approach as you aren't introducing potentially problematic use of invalid code which future version of a browser other than the one you're targeting might actually treat differently.
Even in the absence of any real, technical issues, I'd still consider it to be a best practice policy, now and for the future.
Anyway, I'm still looking for issues and potential issues or definitive confirmation that there are none - and unlikely to be any in the foreseeable future.
Share:
| Bill Posters wrote: |
| Can you recall any details? |
The site in question was done by a customer of ours and they've since fixed it so I can't tell you exactly what the problem was but there were several validation errors in the css which I asked them to fix. After they'd done so I was then able to use the topnav where previously the links just acted like plain text.
Share:
Unless you catalogue the complete CSS support for every version of every user agent ever created (even if it wasn't officially released) then you cannot rely on CSS hacks. There might not be any well-known user agents which recognise something like * html apart from IE, but there might be one which does. Therefore, the only solution is using completely valid code for everything with no alternative rules. That way, the only problems will be from shoddy user agents and not from the page author. Inaccessibility would therefore be the fault of the agent manufacturer and not the company whose website it is.
Code which is actually invalid is obviously unacceptable for a professional project. However, I have some sympathy to CSS hacks which use valid code, especially for people relatively new to CSS (like myself, lol). For serious professionals, it should be possible to create CSS layouts with the same code for all browsers. Using CSS hacks is essentially writing proprietary errors into your code, which runs the risk of harming accessibility for many more devices.
It is normal for a Web page to appear differently in different user agents. As long as it remains accessible and does not favour any particular set of proprietary quirks, it is a good Website. However, since the Web is dominated by very few shoddy browsers with a vast array of unknown minority agents, this idealism may be unrealistic?
Since Internet Explorer is the main requirer of coder TLC, using its conditional comments system to send an alternative CSS file can be a more elegant solution than duplicating CSS rules with proprietary modificatins. Because they are comments, they are simply ignored by all other browsers which understand HTML comments.
Share:
The need for CSS hacks doesn't dissipate with experience and professionalism, it's related to how precise the output needs to be. With a little leeway, then yes, most layouts can be acheived without overt hackery, but if the client demands pixel perfect (and that's not necessarily wrong) then CSS hacks may be the only way to acheive it. CSS hacks are, after all, infinitely better than HTML hacks, and more likely to be supported than DOM-based hacks.
Now valid CSS is better from the point of view of interoperability, but only interoperability of design; design is not content, and design impacts on accessibiility are not archetypally caused by invalid CSS - we know that the major CSS stumbling blocks for assistive devices are things like display and visibility, which are perfectly valid; there are also issues like contrast, font sizing and color choices - again, nothing to do with validity.
So overall, I agree with the original protagonist - CSS validation is not an accessibility issue
Share:
| brothercake wrote: |
| The need for CSS hacks doesn't dissipate with experience and professionalism, it's related to how precise the output needs to be. With a little leeway, then yes, most layouts can be acheived without overt hackery, but if the client demands pixel perfect (and that's not necessarily wrong) then CSS hacks may be the only way to acheive it. CSS hacks are, after all, infinitely better than HTML hacks, and more likely to be supported than DOM-based hacks. |
The question isn't really 'hacks' versus 'no hacks', it's 'hacks which validate' versus 'hacks which don't validate'.
| brothercake wrote: |
| …overall, I agree with the original protagonist - CSS validation is not an accessibility issue |
But what of cases where invalid CSS can negatively impact on the ability of users to access nav menu items, as mentioned by Daz (instances which I'm certain I've experienced myself)? Whilst accessibility problems are not archetypally caused by invalid CSS, it is certainly true that invalid CSS can result in an element on the page becoming inaccessible to certain users in certain common circumstances, whilst remaining accessible to other, more forgiving UAs.
Whilst both browsers are increasingly likely to treat the correct and valid instance of a declaration similarly (due to increasing levels of standards support), differences arise in how they treat incorrect and invalid instances. UA developers are moving towards a unified treatment of valid code, but their treatment and tolerance towards invalid and improper code shows considerably less unanimity.
My thinking was that we can only really guestimate (with any expectation of accuracy) the likely ability of future UAs to support the compliant use of CSS. It is far harder to guestimate the likely tolerance levels a future UA will have to any specific non-compliant use.
Whilst some UAs may correctly ignore a non-compliant use, some may implement it, some may corrupt and ignore all subsequent CSS and some may even refuse to work at all whilst the error is still present (e.g. in a manner similar to the XML parser's demand for well-formedness).
It's my concern that the use of non-compliant CSS in order to exploit idiosyncracies in a browser's tolerance is the least stable and predictable of the available options.
The view of the original protaganist was that they saw no benefit to using options such as conditional comments when the (non-validating) underscore hack appeared to do the job just as well today.
It was my view that we should certainly avoid implementing invalidating hacks within otherwise valid stylesheets, particularly if we consider ourselves to be in agreement with the general aims of the web standard movement.
It's my view that things such as conditional comments (and other non-invalidating hacks/methods) have a more predictable development path so are less likely to throw up problems in the foreseeable future - and as such, they offer a 'best practice' option when targeting browsers with CSS-based hacks.
This also extends into the point of interoperability. If we can't be sure of UA X's reactions to the presence of non-compliant instances of CSS, then how sure can we be that users of that UA can actually use the page and access its content?
Anyhoo…
Last edited by Bill Posters on 15 Oct 2005 10:33 am; edited 3 times in total
Share:
Assistive devices are not the only ones which access the Web. To ensure accessibility in CSS-enabled devices, particularly handheld and printing devices, valid CSS is required. Forgetting to close a ruleset or put speechmarks around a font face would be invalid CSS and this could cause accessibility problems in devices which did not handle this type of error in an elegant manner. This is especially true if the error is early on in the stylesheet.
The use of comment hacks inside audio CSS property values and other invalidating CSS hacks are also accessibility concerns. The response to invalid CSS is unpredictable, especially with handheld devices which can be put under real strain by trying to process such things. We may think of handheld and print devices as being exotic, but in fact they are very mainstream when compared to other devices which access the Web. Fridges, televisions and even some games consoles like the Playstation Portable (PSP) have CSS-enabled browsers whose response to broken rulesets and dubious element values cannot be predicted.
Due to the thousands of Web-enabled devices which are increasingly divergent in their features, standard code is essential to have the best change of device accessibility. From the HTTP conversations to the markup, CSS, character encoding, image formats, etc, etc, the use of absolutely standard code is the critical first step in producing a coherent page for as many users as possible.
Valid CSS is a device accessibility concern in the same way that valid markup is a device accessibility concern. If the device cannot access the content then neither can the person (many handheld devices will produce garbage from invalid CSS or crash from invalid markup). In addition to validity, best practises are required to ensure human accessibily (colour contrast, link styling, etc) in the same way that best practises are required in markup (alt parameters, <noscript> elements, etc) to ensure human accessibility.
Well, that's my understand of it, anyway.
Share: