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?

3 Answers 3


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.

  • Great - thanks for the info about screen readers, and also for the point about 508 and WCAG. I think you and Andrew both have answered my question: this requirement is about structure and order, and not about a css-free browsing experience. Our structure and order are good and markup is mostly semantic (working on replacing legacy bits like click-handled spans...). For planning purposes, we should concern ourselves with the accessibility of UI widgets but not with their appearance when css is disabled. I'm selecting this as the best answer for good summary and bonus info about screen readers.
    – aames
    Jul 30, 2015 at 14:01

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.

  • My understanding of screen readers, though, is that many/most respect "display:none" and won't read those elements, so the requirement to disable css actually is more onerous than the requirement to be understood by a screen reader.
    – aames
    Jul 29, 2015 at 18:28
  • Also, if you wouldn't mind, can you give me examples of which screen readers would fall into each of your two categories? I would like to try them and see what the experience is like. Thanks!
    – aames
    Jul 29, 2015 at 18:37
  • Also, I believe that at least some screen readers support the html 5 "hidden" attribute, is that correct? We have made an effort to produce semantic markup and will continue to do so, but we do have things like asp.net validators that are always present and are shown or hidden as necessary. However, we can easily update our client-side code to toggle the "hidden" attribute on the validators themselves, as well as apply an "aria-describedby" attribute to the related inputs when the validators are tripped.
    – aames
    Jul 29, 2015 at 19:57
  • @aames, I'm afraid my knowledge of screen reader software packages is fairly dated, grounding out about a decade ago - I just follow their capabilities now although this page seems to be a farily good starting place: en.wikipedia.org/wiki/Screen_reader#Web-based_screen_readers Jul 29, 2015 at 20:04
  • display: none; quite deliberately removes the element completely from the DOM, that's the purpose of this property value pair
    – Toni Leigh
    May 10, 2016 at 16:11

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.

  • I will admit that some of our code is not ideal from an accessibility standpoint, but it is also a giant codebase, in some cases ten years old or more. We're not talking about marketing material here... we're talking about something more along the lines of Salesforce.com. It's also based on a server framework that is not, out of the box, even remotely accessibility-friendly. We have to pick and choose what we can reasonably hope to tackle without completely re-engineering our application, which is not practical.
    – aames
    Jul 29, 2015 at 18:52
  • Also, I'll ask you the same question as Andrew: what are the "better" screen readers you refer to? I've tried NVDA and ChromeVox, though not extensively and not intentionally listening for the appearance of what should be hidden content, though I will try that.
    – aames
    Jul 29, 2015 at 19:07
  • One more thing. :-) The jQuery UI tooltip seems very accessible for both keyboard users and screen reader users. It creates the tooltip on the fly from the value of the "title" attribute (or whatever you supply) and adds an "aria-describedby" attribute to the tooltip target which points to the id of the new tooltip element. But... if you disable css and then mouse over a tooltip target, you'll get text that overlays other text on the page (because the tooltip positioning has to be applied inline), which is totally unreadable - the sort of thing a sighted tester with a toolbar might object to.
    – aames
    Jul 29, 2015 at 19:25
  • Hm. Apparently I can add a comment. I swear it wasn't letting me when I started that response. It was too long to include here just the same.
    – Thomas
    Jul 30, 2015 at 3:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.