In my case, being disabled really is lame. That’s right, I’m unable to walk. Did you assume I meant “lame” in another way? Curious. I’m so very interested in the meaning of words but, more specifically, how I relate to their use. What does the all-encompassing and rather generic classification of “disabled” actually mean to me, a person with disability?
Read “being disabled can be lame” in its entirety over at simplyaccessible.com
In honour of Global Accessibility Awareness Day (GAAD) today I’m throwing this method out in to the ether that is the web. However, it’s not the quote/ unquote “technique” I’m offering — in the sense I really expect anyone will use it. Rather it’s my aim to try and get people thinking about the content they consume and produce on and for the web, period. And thinking a little differently about said web content.
After all, that’s the point of going through the effort of raising awareness. To think about anything in a manner which you aren’t typically conditioned to think about them. Or in other words, it’s not so much the result I’m most interested in here, it’s the reasons for and process that give us that result. It’s my hope to draw some attention towards automatic text transcriptions of audio only podcasts, specifically.
And I’m aware such a solution is still a ways off from being practical — as in reliably useable. But it’s never too early to entertain prospects. And experiment. Read “Automatic audio text transcriptions” in its entirety
I’ve spent some time over the past few months thinking about how I craft the content I publish for the web. Specifically regarding my use of language when writing. In one certain context — not to suggest my writing is free from more problems in others — it’s not as inclusive as it should be.
I’m referring to how a screen reader user experiences the words I write. And with my limited use of the technology, I’ve taken note of something quite specific. If you use a screen reader to speak my words, I’m not sure you, as a listener, will get all of the “subtleties” (case in point) of my intent.
Using the example I cited immediately above, precisely how is a screen reader user supposed to know I’ve put the word “subtleties” in quotation marks? Just typing quotation marks before and after the word isn’t enough to make a screen reader speak them. Read “Language is a curious beast, ain’t it?” in its entirety
Earlier this week Aaron Gustafson turned me onto an accessibility feature in Google+. In your “Settings” Goggle+ gives you the option to turn on “Accessibility,” to “change the presentation of some pages to work better with screen readers and other assistive tools.”
A noble goal towards inclusivity. But one thing unfortunately sticks out for me, why is this even an option? And an option a user must opt into?
Turns out the reason wasn’t as misguided as I first thought. Don’t get me wrong, it’s still totally counterproductive — accommodating what they’ve already implemented to meet a goal that would be better served if Google strove for this goal up front? 1 But, I guess, effort is being made to provide people the support they might need to better their experience. My “complaint” should be taken with a grain of salt. It could be worse. But at the same time, it it should be much better. Read “Some shortcomings in Assistive Technology?” in its entirety
In my last post, The frustrations of VoiceOver, I alluded to “actively using Git/ Github in my workflow to my advantage” in the process of building a WordPress theme, bA53. And I’m still on it. But I’d very much like to flesh out a few idea’s concerning how I use Git towards my web development efforts.
What is Git? While one couldn’t be blamed for thinking I’m referring to the British noun “git” — and no, I’ve never heard of it either prior to tripping over it on Google — which apparently means an “unpleasant or contemptible person,” I’m not.
Rather Git, I’m speaking about the software now, “is a distributed revision control and source code management (SCM) system with an emphasis on speed.” I’ve mentioned my use of Git previously, as far back as my first post on this blog, in fact.
But I’ll save you from the pain of having me actually explain something I (still) barely understand, so I’ll simply recommend watching these 4 video’s that do a far better job of explaining Git than I could ever do. And it’s done. Read “Some more meanderings on Git” in its entirety