WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Question about Accessibility plugins

for

From: Birkir R. Gunnarsson
Date: Jun 7, 2019 1:12PM

Good discussion.

Just to clarify, for anyone who is a newbie to the whole thing.
There are two types of overlays:
1. Accessibility unicorn overlays - overlays that make your site
accessible automatically. These accessibility unicorn overlays do not
exist. Anyone that claims their overlay automatically fixes
accessibility is practically scamming you.
2. Custom accessibility overlays - overlays that someone will develop
specifically for your website. In order to do so you have to pay them
to assess your site, to write the overlay and to update the overlay
whenever you make any changes to the site. Though these work in
theory, they are costly and do not build the knowledge or culture
necessary for sustainable accessibility. Eventually you'll have to
cancel the overlay subscription and do all the work you should've done
in the first place.

There is a third category, server-based accessibility options
(server-based toolbars that let users customize the font, size, colors
or have the webpage read out loud).

There is nothing wrong with having those options as an enhancement
(seriously, does your grandma know how to use browser zoom?) but those
do not constitute making your site accessible. The site must first be
made accessible before you consider those tools as an enhancement.
Incidentally, most server based screen reader tools are pretty
useless, they may work on static pages with a lot of content, like
news articles, but fail utterly for any page with interactive content.

I find documents to be a little bit more vendor friendly.
We receive documents from various business units with important and
time sensitiv info that urgently need to be posted to a website.

These can be written by anyone of hundreds of employees, many of them
are non technical, using any of 10 different authoring applications.

In this scenario training and standardization is not going to take us
very far. There are too many potential authors for that.
The only way to ensure documents are accessible is to test and add
accessibility at the time of posting.

At that point you could train your content team and provide them with
ttools, like Adobe Acrobat Pro or you could work with a vendor to do
this for you.

I can't say which approach I chose for my organization, but will say
that there are reasons why a reliable vendor with a lot of expertise
in the document accessibility industry and with experience and tools
to det the job done quickly and efficiently would make sense in that
scenario.

It is not ideal, and if you have smaller teams you should always
emphasize knowledge, processes and tools over remediation, but In my
scenario I had to resort to the remediation option.



On 6/7/19, <EMAIL REMOVED> < <EMAIL REMOVED> > wrote:
> As a business person with an MBA, I don't know how managers can justify the
> band aid approach: it just throws good money at media (websites, documents,
> PDFs, ePUBs, A/V, whatever) that wasn't built correctly to begin with. An
> elementary break-even analysis (B/E) would show this clearly.
>
> A similar model used in our American medical culture. Don't cure the
> disease
> or prevent it: just medicate it into submission and keep milking the
> population for the long term.
>
> There's a time and place to take medicines, as well as to patch a website
> or
> document with this technology or that one. But the majority of stuff should
> be built correctly right from the start. Everything would run so much
> smoother.
>
> - - -
> Bevi Chagnon, founder/CEO | <EMAIL REMOVED>
> - - -
> PubCom: Technologists for Accessible Design + Publishing
> consulting . training . development . design . sec. 508 services
> Upcoming classes at www.PubCom.com/classes
> - - -
> Latest blog-newsletter - Accessibility Tips at www.PubCom.com/blog
>
>