One thing you can do(though it takes some doing, and will break a great many websites good and hard; because their ‘style’ sheet is a bit too tightly coupled to their content and scripted material) is to employ a custom user stylesheet to override the site-provided one. For some reason, browsers have been moving in the direction of requiring multiple layers of obscure fiddling, where they used to have much more obvious support; but it is still there.
Because web design tends to be deeply inaccessible, you may need to be a bit of a guru to build a custom stylesheet that actually helps you and doesn’t horribly munge the target page; but it can be used to override some webdev’s little horrorshow.
For those who have not tried NoScript, it is not all-or-nothing. You can enable only those connections which you trust. So, for your average modern a-go-go page you might need to enable a handful of connections, but leave a dozen or two off. And you can store these selections so you rarely need to change them for a given page. But there is an initial effort curve.
Another option is to copy the other domains the scripts point to and add the worst ones to your “hosts” file so that your computer won’t connect to them with any browser.
Most discussions of accessibility, when it comes to web sides, focus on accessibility to different browsers. But apart from web design, accessibility to people with differing needs.
But for the user to configure things to fit her needs, she needs to be able to configure her browser, and the browser needs to be able to draw the website accordingly, and the website musn’t prevent the browser doing so.
So the first concept of accessibility is necessary for the second but not sufficient.
Aside from that: text-encoding trouble, not being able to choose MY fonts for MY needs, small fonts, hard-to-read fonts, low or no contrast, text that wanders off the right or left side of a browser window with no lateral scrolling, important buttons that lie just under the bottom of the browser window, flashing images, animated backgrounds, autoplay, autoload/endless scrolling, anything that breaks back and forward, anything that breaks searches, timers, for the blind anything that breaks text-to-speech functions, anything that requires close coordination, not disability-related but anything that requires stable connections…
A few more: anything that requires everyone to type everything right the first time, tumblr tags are particularly egregious because you can’t edit as you type, only delete and start over, anything that relies on passwords but doesn’t tell you it is truncating the passwords or is only using certain characters, so when you retype the exact same password it doesn’t work, anything except Facebook that requires a Facebook account, etc.
AdBlock can also be set to block specific sites or scripts; I’ve done that on sites where I want to allow most things through, but selectively disable nuisances.
I think listing misfeatures, listing things to check, and setting up a checklist and a couple special browser configurations could make it a bit easier for web designers to recognize bad design.
“What does this browser test?” “Oh it’s just the basic out-of-the-box Firefox except that it uses 18-pt OpenDyslexic.” “Why would anyone use such an extreme configuration?” “Oh maybe they want to prove you wrong. Or maybe they are dyslexic. Or maybe they want to see a small screen from a distance without eye strain.” “But I’ve done everything for 9-pt Times.” “My point exactly. After this, we’ll check cookie blocking and Adblock and Flash blocking…” “Nooooo!”
And this goes beyond web issues, but if the only way to report accessibility problems is to use phones, they can be another accessibility problem that the affected people can’t report.
