skip to main content

Posts tagged “accessibility”, page 2

  1. Accessibility is not a feature.

    Ethan Marcotte:

    Lately, I’ve been reflecting on some of the language I use to talk about accessibility—or, more specifically, to talk about the people I’m designing for. Like, I’ve spoken in the past about “screen reader users” or “users who navigate primarily by keyboard.” (Heck, maybe you have too.) And I’ve been wondering if that language is problematic, since it implicitly treats those groups as monoliths: as though every single person using a given piece of assistive technology would browse, behave, and think exactly the same. In other words, if two different people visit your site with the same speaking browser, each of those people will have their own expectations of how a website should work, and how information will be arranged.

  2. Game Maker’s Toolkit: Making Games Better for Gamers with Colourblindness & Low Vision

    Mark Brown’s “Designing for Disability” series seems to be very comprehensive and well researched. I’m moderately colorblind and feel very well represented by this video.

    It reminded me of the game I most wanted to love but just couldn’t play: Puzzle Bobble. If a level had both blue and purple bubbles, I was toast. Even though each bubble color had a different shape inside, the differentiation wasn’t enough for split second decisions.

  3. Securing Web Sites Made Them Less Accessible

    Eric Meyer experiences internet access in rural Uganda:

    For geosynchronous-satellite internet access, the speed of light become a factor in ping times: just having the signals propagate through a mixture of vacuum and atmosphere chews up approximately half a second of travel time over roughly 89,000 miles (~152,000km).

    But that’s not the real connection killer in most cases: packet loss is. After all, these packets are going to orbit and back. Lots of things along those long and lonely signal paths can cause the packets to get dropped. 50% packet loss is not uncommon; 80% is not unexpected.

    A local caching server, meant to speed up commonly-requested sites and reduce bandwidth usage, is a “man in the middle”. HTTPS, which by design prevents man-in-the-middle attacks, utterly breaks local caching servers. So I kept waiting and waiting for remote resources, eating into that month’s data cap with every request.