What follows is my part of a talk I gave with my two colleagues, Rob Harvie and Sandy Feldman, at The Accessibility Conference at University of Guelph, Wednesday May 27th, 2015. And since it’s original publication, this piece has been moderately re-written in anticipation of a re-presentation at Accessibility Camp Toronto 2015 (Session 3, Track D), Saturday October 17th, 2015.
The idea of penalty doesn’t belong to the law exclusively. It’s a penalty when a person can’t use technology they need.
Hello! My name is Johnny Taylor. I’m a disabled web worker. And it’s my job to keep web accessibility non-elite! But first, I should paint you a picture concerning me and the reason I’m speaking to you, here, at the fifth iteration of Accessibility Camp Toronto today.
Way back, in the summer of nineteen ninety-six, when I was all of twenty-one years old, I was involved in a very serious motor vehicle accident, which left me in a coma for two months (or there about). And that, getting straight to the point, is my personal motivation for practicing inclusive design. Read “Stranded between empathy and penalty” in its entirety
This past Global Accessibility Awareness Day (GAAD) I was fortunate enough to catch part (as in a wee bit) of Inclusive Design 24 (#ID24). The Paciello Group held 24 one-hour webinars concerning various matters dealing with accessibility. It was really quite the productive gesture to, and I’ll quote, “celebrate efforts worldwide to ensure people with disabilities have full and equal access to the web.”
Remember — and not to suggest this was The Paciello Group’s intent when offering their statement about #ID24 — “if what one is unable to do continues to be used as a means of defining disability […] then every single individual on this planet is disabled.” That statement brilliantly sums up an intent of GAAD quite nicely, so says me. It’s all inclusive.
And one “webinar” in particular got my noodle cooking. The Billy Gregory’s talk, 10 Things I Wish I Knew When I Started in Digital Accessibility. Not that any talk I was able to tune into wasn’t great. But it was this one, however, that was personally relevant. In the sense I found myself thinking a lot about how I’d answer Billy’s proclamation. Read “The use of technology will always require adaptation” in its entirety
An interested party left a comment on a post I wrote back in November of last year, called The frustrations of VoiceOver. The commenter wondered if the situation I described in said post was the same for VoiceOver in Safari on iOS (meaning on both the iPhone and iPad). Problem being, I had a one helluva time testing the “bug” with VoiceOver on iOS.
Long, and somewhat uninteresting (for the scope of this piece, at least), story short, I was able to clear the biggest impediment I had toward testing this quirk in iOS yesterday. How do I even turn VoiceOver on to test? It, as in iOS, will not recognize my double taps when it asks for confirmation for turning VoiceOver on. “Is this really what you want to do? iOS’s gestures change when VoiceOver is turned on” (I’m quoting from memory, it’s more than likely that isn’t what it says). So I put a call out on Twitter asking how I might overcome this.
Although the solution isn’t all the intuitive to discover on one’s own, that doesn’t necessarily make any solution any less liberating or powerful. Read “The Split Tap” in its entirety
First off, the title of this post is obviously link bait. I don’t seriously believe this to be a real “issue.” But if you’ve not read my last post, it might be worth reading for some context, I’ve found an answer as to why I was having issues using VoiceOver. And I thought I’d share.
What I didn’t divulge last post was I was primarily trying to use VoiceOver with my work. Again, as I alluded in my previous post, I’m talking about VoiceOver on OSX. For sometime I’ve been very casually building what I refer to as “an orderly, semantic mark-up centric, un-styled and accessible WordPress starter theme” — for which, as of this writing, it’s technically none of the above. But I’ve named it bA53.
My goals with this personal project are many. But most importantly I’m using this opportunity to push myself to learn about a few different aspects of web development, specifically. Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA), how Screen Readers actually interact with what I build and actively using Git/ Github in my workflow to my advantage — I’m the master of the tiny commits and the much too frequent push’s. Read “The frustrations of VoiceOver” in its entirety
So for quite some time now, much longer than is even remotely justifiable in fact, I’ve been having my share of difficulty both with using and understanding how to use Screen Reader Technology. Or more to the point, I just don’t get how this particular technology is usable to Blind and Low-Vision users.
Just to be crystal clear, I’m not knocking the technology or anyone who uses it, I’m only speaking towards my experience with it. And since my experience is limited, take this for what it’s worth, which isn’t a hellva lot.
Using said technology is an almost maddening endeavour each and every time I try to use it. I cannot wrap my head around making personal, productive use of it — and when I refer to “it,” in the interests of full disclosure, since I design and develop on a Mac, I mean VoiceOver. Read “My life with a Screen Reader” in its entirety