Category: Accessibility

There are 158 posts filed in Accessibility (this is page 7 of 27).

Listened Job Insights: Meet Business Relations Specialist Pam Gowan – 45 Years of Enhancing Job Opportunities and Educating Businesses of the Possibilities and Abilities of the Blind and Visually Impaired by @BlindAbilities from Blind Abilities

Business Relations Specialist, Pam Gowan, has worked at State Services for over 45 years and with retirement just around the corner. Lisa larges, Outreach Coordinater at SSB, sat down with Pam to talk about Pam’s history at SSB and walk through the process a customer/client would experience or expect when a counselor enlist the services of an employment specialist such as Pam Gowan.

I’m sharing this for two reasons, even though the audience for this site isn’t typically blind people on the hunt for employment.

First, to help a fellow blind creator out, and second, because said blind creator isn’t making excuses and does the work to transcribe their podcasts while giving the content away for free.

If Blind Abilities can manage this, then the blind people insisting on using Facebook Live despite its lack of support for captions or transcription can manage this too.

Blind Abilities isn’t staffed by developers and they don’t have anyone who can advise them on the best way to go with their WordPress site on staff either. We’re not talking about someone who spends all day playing with servers and software.

And yet, they managed to not spend their time making excuses for why they can’t, or why they don’t want to, instead spending their time doing the right thing with regard to accessibility.

So thanks, Blind Abilities, for doing the right thing, and I’ll happily promote your work because of it.

I bookmarked a post by Heydon Pickering entitled Web Accessibility Is Out To Get You And Make You Feel Sad and my sharing of that post received some feedback from one of the developers who was apparently involved and who has made the accusation that Heydon is attempting to hide his abuse by lying about everything he did during the conversation.

I’ve asked for a link to the relevant conversation, and so far haven’t received a response, so in the meantime, (assuming that this individual has the best of intentions, giving benefit of the doubt and all that), I’d like to get an honest answer to the question which forms the title of this post, because as both an accessibility practitioner and as a person with a visible disability who quite literally is reliant on whether or not accessibility is viewed as more than just a nice-to-have by developers, I’m tired.

I bookmarked Heydon’s post because quite frankly it telescopes excuses for inaccessibility I hear on a regular basis from developers, and yes, I’m glad someone can manage to create some humor borne out of what is very draining: Advocating for accessibility.

Advocating for accessibility and in some cases fixing accessibility issues in code is draining because there appears to be no end in sight, and experience tells me that even if I wade into a code base, make accessibility fixes, leave detailed comments explaining the fix, more often than not for free, and the pull request is accepted, that fix will be reverted or broken in some other way and it’s only a matter of time as to when this will happen. And that’s the ideal situation. I can wade into a code base, propose a fix, and for the most part be guaranteed a protracted argument, sometimes over a single line of code, about why that accessibility fix won’t go in, and we swear we care about accessibility and we’re never going to admit anything but the purest of intentions and don’t you dare call us ableist because that will hurt our feelings.

And I’m far from the only accessibility practitioner who gets to experience things going down like this.

If you’re a person with disabilities, even one who doesn’t professionally work in the accessibility space, you are expected to advocate and educate for your entire life, most of the time for free, except when you’re inspiring the living daylights out of abled people through the videos and photos they take, often without your consent, which they then post on social media and through which they enjoy viral internet fame.

Oh and you’re also expected to be polite, ask nicely for the accessibility crumbs you manage to catch falling from the table, and God help you if you file a lawsuit because lawsuits are bad and well to be honest they’re evidence of your ingratitude.

This is a battle we have been waging on the web for the last twenty years. Accentuating the positive hasn’t worked. Providing business case after business case hasn’t worked. Pointing out the benefits to everyone who isn’t a person with disabilities hasn’t worked. Fixing your code for free hasn’t worked. Thousands and thousands of hours of free advice and training and examples hasn’t worked.

So yeah fellow developers, I’d really like to know at what point accessibility folk are permitted to lose our patience with all this without you stomping your feet and crying fowl, and I’d really like to know what exactly will convince you to do the needful, learn the basics, and start creating things that everyone can use without having to badger you into it so we can quit going over the basics time and time and time again and focus on fixing actual issues.

What exactly is the magic solution to ending this fight and not spending the rest of my life advocating for my civil rights and training you and inspiring you because if there is some magic solution I will gladly employ it so I can stop giving a damn about accessibility and just live my life like a normal person.

Signed:

A web developer who is absolutely exhausted by constantly fighting with the rest of you.

Bookmarked Web Accessibility Is Out To Get You And Make You Feel Sad by Heydon Pickering (heydonworks.com)

Since the landmark Domino’s case, I’ve been having some conversations about web accessibility with people who wouldn’t ordinarily take an interest. Some of these conversations have been productive; others have not. The following is a dramatization based on true events.

This is a good read to keep on hand for those days when you’ve lost your patience with the pushback regarding web accessibility and will probably be necessary until things like punching people and daydrinking become acceptable options for coping.

I’m still laughing. This is the funniest thing I’ve read when it comes to web accessibility in a very long time.

Wow. Basecamp’s gotten a metric ton of accessibility improvements.

Finally, reasonably accessible project management.

I have a lot of catching up to do to get in line with the way everyone else manages their projects, but I suspect my life’s about to get a lot easier.

Mmmm fewer spreadsheets and fewer hacky internal applications.

Bookmarked Accessibility Inspector by Mozilla (MDN Web Docs)

The Accessibility Inspector provides a means to access important information exposed to assistive technologies on the current page via the accessibility tree, allowing you to check what’s missing or otherwise needs attention. This article takes you through the main features of the Accessibility Inspector and how to use it.

Watched
I used Noter Live to generate these takeawayss, post them to Twitter as a thread, and generate the HTML with Microformats 2 to then post on my website. It’s really easy to use, very accessible, and is great for helping to ownw the content I create.

As with all Inclusive Design 24 talks, this one will include captions soon after the conference is over.

Marco Zehe:

Marco has worked for Mozilla since 2007, always in the accessibility field. He does quality assurance. He also worked for Freedom Scientific and helped with braille display dev in the early 2000’s.

Accessibility inspector is a new addition to Firefox dev toools, it’s a year old now.

Mozilla wanted to make sure devs could make their sites more accessible without having to download extras.

accessibility inspector allows devs to inspect the accessibility tree as presented to assistive technology users.

Latere versions introduce auditing features to highlight easily solvable problems. Helps devs solve problems and lets them see the problems go away.

Accessibility inspector is inside dev tools beside the HTML inspector. can be turned on in the context menu as well.

Unless you’re a screen reader user, turn on accessibility engine first.

Turn off when not using because it slows down the browser thanks to extra processing. If you turn off for one tab it turns it off for all.

Screen readers can’t accidentally turn off the accessibility engine.

Marco is demoing the tree views of the inspector.

Inspector is fully keyboard accessible.

If you have more than one tool bar on a page make sure that they are labeled and state their purposes. Marco is citing chapter and verse of WCAG.

Another cool visual feature: Accessibility highlight. Use the mouse to highlight and info bar shows complete color contrast for all colors and shows which ones pass.

Mozilla is trying to advance auditing with machine learning. Trying to determine whether or not machine learning can help. Finds patterns for fake elements.

Helps with div soup.

Mozilla wants feedback. Bugzilla, Twitter, public chat facilities.

The inspector can output its results as a json file.

Import resultant json into your tool of choice.

You can use the inspector as a blind/VI person. Sweet! Gonna go play with this now.

The info from the inspector is available on Linux as well, so you’ll get good enough results to not have to worry about switching to Mack/Windows screen readeres.

Marco attempts to avoid Chrome V. Firefox accessibility toools death match. Playing this well.

You can make dynamic changes in the dom inspector and they will be reflected in the accessibility inspector. Seems like this could be great for temporary hacks by screen readers.

Oh hey it’s @aardrian!

Mozilla’s accessibility team heavily collaborates with the other teams. Collaboration is facilitated. WordPress, please take note.

Thanks Marco, this talk was excellent, and I’m looking forward to playing with this.