How practical is the accessibility requirement to view pages with CSS disabled?

Question

As a practical matter, aside from what Section 508 states about web documents being readable without relying on an external stylesheet, do vision-impaired users really try to browse the web with css completely disabled? If so, is there a particular browser or add-on that would typically be used?

Most of the tools I've used to disable css in Chrome and IE either disregard css that is dynamically injected, or have to be reapplied on each page load, or both. I can't find a native way in these browsers to disable all css, and using they types of add-on tools I've just described to try and browse the web with css disabled seems both unreliable and painful.

In Firefox you can disable all css via a menu option, but this also turns off support for the html5 "hidden" attribute. Again, this does not seem like a practical way to browse the web.

We have customers who are using IE + the Web Accessibility Toolbar from The Paciello Group to test our apps for 508 compliance. One of the requirements is that all of our pages be usable with css disabled, and we have gotten dinged for having things like modal dialog content and field validation messages show up when css is disabled. Most of our pages are not documents but complex data displays and forms. We have our markup structured fairly well so that the content is grouped nicely with proper headings, we have aria landmarks on the nav and main content areas, etc., and the content itself is pretty readable without css. And then... we also have 3rd-party widgets like the jQuery UI date picker and select2, and the internal components mentioned above like modal dialogs and validators, which are highly dependent upon css in order to make any sense at all.

This article, also from the Paciello Group, clearly suggests using css to hide things because that method enjoys the widest support: http://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/

So the group that suggests using display:none to hide content for greatest support also produces a tool that prompts testers to object to the use of display:none. Which leads me to ask... does anyone anywhere really try to use the modern web with css disabled, or is it much more practical to make sure our app doesn't break if people zoom the window or use their browser options to change font sizes and colors?

Answer 1

Wow. I can't even reply to comments to my own response until I get 50 rep points? Talk about usability...

@aames, all good questions.

I fully understand the situation with your code base. Having worked at Salesforce in both a UX and Dev capacity, particularly around accessibility, I know what it's like dealing with legacy code and developers who don't know a SPAN from a TD. The only time they started to get caught up with 508 compliance was when they created a new framework and started rebuilding everything with that. That's the team I was on when I ended up leaving for another job. But, yes, you take what you can get.

The "best" screen reader is Jaws. If you had to focus on appeasing one screen reader it would be that one. It's certainly the most popular though NVDA has made leaps in the past few years. At Salesforce we focused Jaws/IE and VoiceOver/Safari for Mac. They don't share the same set of accessibility APIs though they do overlap so a solution for one won't always work for the other. Usually they do though.

jQuery UI has gotten a lot better around accessibility. I'm very impressed with it in that respect and happy to see it evolve. Their tooltip is a wonderful example of good accessibility and I wouldn't hesitate to use that technique. It is 508 compliant and if someone is telling you different I don't think they're fully aware of how the spec works. The only thing I'd do differently is insert the HTML for the tooltip immediately after the DOM element that is triggering it so that it flows more naturally with the content it is relevant to. That's not necessary but it is a little "nicer".

Also keep in mind, 508 is also painfully outdated. WCAG is a much better standard to work towards and is the basis for the revised 508 specifications. But again, the CSS turned off angle is really meant as a guide to make sure the structure and order of content makes sense on its own. If you have a footer don't put it first in the DOM and use CSS to make it look last. That sort of thing. Well, also things like using heading tags not styled DIVs, actual anchors instead of spans styled to look blue/underlined with onClick for navigating somewhere (I've seen it done) etc.

Answer 2

The requirement for running pages without CSS enabled is there to ensure that your pages make sense when the user is reading them via a non-visual device such as a screen reader. The problem here is that some screen readers do actually read what is on the screen while some read the underlying HTML. The first kind usually produce a chaotic stream of garbage that the user side-steps by skipping from link to link (thus you need to make sure your links have meaningful text content and no just "click here"). The second kind tend to make more use of the naturally semantic markup to understand the content of the page, helping the user understand what is heading text, what is body copy, what is a paragraph, what is an image (preferably with a good alt description), etc. This second kind cannot be fooled by moving stuff around using CSS therefore, to be available to those readers using those screen reading devices your page MUST make sense when viewed without CSS.

Answer 3

Andrew is exactly right (I can't comment yet, not enough rep points). The idea of CSS disabled is not meant as an actual browsing experience but to ensure that your content makes sense semantically and in the order it's presented because that's how, the better, screen readers evaluate the content.

On the idea that the same group suggesting display:none is also suggesting don't use display:none... the ideal way to handle dialogs and error messages is to creating them dynamically, not put all possible messages and errors in the DOM and show/hide them as needed. If they're going to be embedded as you have them, yes, display:none is the way to go but, again, it's not ideal.

I know you're not saying this exactly but using 3rd party UI libraries does not excuse a site from being accessible. Though they've gotten much better in recent years many UI libraries are not accessible or are poorly structured. jQuery UI is one that's gotten a lot better but it's not complete yet. So far as I can tell their date picker isn't accessible (certainly not to the degree is could and should be) to begin with so the fact that it doesn't make sense with CSS is a moot point.