E-mail List Archives
Re: Question about Accessibility plugins
From: Lucy Greco
Date: Jun 12, 2019 12:01PM
- Next message: Karlen Communications: "Comparing Results of Tagged PDF with Acrobat and Alternatives"
- Previous message: mhysnm1964@gmail.com: "Re: Difference between JAWS and NVDA for accessibility testing"
- Next message in Thread: None
- Previous message in Thread: Birkir R. Gunnarsson: "Re: Question about Accessibility plugins"
- View all messages in this Thread
hello: i wanted to add a note to what was said here i agree over all but
some of the toolbar options can actualy make your site hard to use for AT
users. i have found that some of the toolbar tools tend to draw focus and
or block other AT from working properly on your stie. lucy
Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces
On Fri, Jun 7, 2019 at 12:12 PM Birkir R. Gunnarsson <
<EMAIL REMOVED> > wrote:
> 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
> >
> >
- Next message: Karlen Communications: "Comparing Results of Tagged PDF with Acrobat and Alternatives"
- Previous message: mhysnm1964@gmail.com: "Re: Difference between JAWS and NVDA for accessibility testing"
- Next message in Thread: None
- Previous message in Thread: Birkir R. Gunnarsson: "Re: Question about Accessibility plugins"
- View all messages in this Thread