WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Naming and labeling tables in Word

for

From: Whitney Quesenbery
Date: May 28, 2014 7:06PM

Jon,

Completely agree with you that usability evaluation - real people using
real tools to do real or realistic work is the way to evaluate for
accessible UX (or usable accessibility).

In usability we talk about getting the non-expert view. This doesn't mean
ranges of skills in using tools (though that is important as well). It
means seeing the web site or software from the perspective of someone who
is focused on the task or goal, rather than on evaluating the software.
Inevitably, we experts have a rich set of heuristics. That's generally
good, but too often this means that easy-to-detect problems get more air
play and we focus on technical correctness rather than a user-centered
view.

When the NCI/HHS Research-Based Guidelines were first published, each
guideline had two ratings:

1. The strength of the research evidence for the guideline. This score was
given based on a literature review.

2. The important of the guideline for usability. This score was given by a
panel of usability experts based on their usability testing experience.

One of the things that quickly became clear was that there were some
aspects of usability that were a little bit over-researched in comparison
to their impact on actual users. That didn't mean the guideline wasn't
important. Just that it was often easy to study and so had been studied a
lot. Conversely, there were guidelines judged to have a big impact on
usability for which there was very little academic research


Thinking about "certifying file converters" I was thinking about the kinds
of certifications that NIST creates for compilers and other tools. It's a
correctness and consistent application of the standards certification.
Nothing to do with users at all.




On Wed, May 28, 2014 at 3:22 PM, Jonathan Metz
< <EMAIL REMOVED> >wrote:

> Well put, Whitney.
>
> Though I disagree with the suggestion to "Forget certifying people. Let's
> have certifications for file formats and converters." We have those
> certifications already, but all it shows is that some people are able
> memorize what to do in certain circumstances for certain programs.
>
> Making Office documents accessible is essentially providing documents with
> the understanding that it's purpose should be for users who require
> accessibility features of software that is able to edit/use docx/ xlsx/
> pptx.
>
> If you start to focus solely on making documents accessible only for AT,
> you run the risk of inadvertently ignoring disabilities that don't
> technically require AT, but may benefit from properly implemented
> accessibility techniques. My recommendation would be to follow the
> suggestion made by Bill Peterson of the DHS, which is to focus on
> designing for standards, not for assistive technology (AT).
>
> More reasons to avoid testing for AT:
>
> ' AT varies a lot – versions change regularly;
> ' Coding to a specific AT device is only as good as the version it's coded
> to;
> ' Sophisticated AT devices like JAWS cheat;
> ' Just because an application works with JAWS does not mean it is 508
> compliant;
> ' Jaws is an AT device, not a *measure of compliance* with 508 standards.
>
>
>
> -Jon
>
>
>
> On 5/28/14, 2:32 PM, "Whitney Quesenbery" < <EMAIL REMOVED> > wrote:
>
> >Sigh.
> >I sometimes (often informally) teach groups how to make Office docs
> >accessible.
> >
> >The advice seems to come in three groups:
> >
> >1. The majority is essentially: Use Word as it was intended to make a
> >correctly formatted document. I find myself saying this over and over
> >again for structure, styles, lists, columns, headings, etc.
> >
> >2. There's a small group of "good practice things to do that are important
> >for screen readers and make the document ready for PDF" This includes
> >thinks like hyperlinks and tables and setting language.
> >
> >3. There's an even smaller set of "things you have to change about how you
> >write" which I think just includes adding alt text, checking
> >color/contrast, and placing images inline.
> >
> >
> >
> >My "sigh" list is:
> >
> >1. If everyone did #1 and #2 as a matter of course, it wouldn't take more
> >than an inter-office memo to teach the additions for accessibility (#3).
> >
> >I've even had companies ask me to teach accessible docs as a way to force
> >people to learn good document structure and plain language, since they
> >won't show up for those topics.
> >
> >2. This stuff is so basic that I don't understand why we can't have
> >consistency across the applications. Please. Please. Please.
> >
> >Maybe we can stop "innovating" long enough to get simple things right. So
> >that the screen readers can finally actually learn to read the file
> >formats. And so that the conversions between formats (Office to PDF and
> >Office to Web) will work correctly. They are just bugs as far as I can
> >see.
> >
> >Forget certifying people. Let's have certifications for file formats and
> >converters.
> >
> >
> >
> >
> >
> >On Wed, May 28, 2014 at 1:06 PM, Jonathan Avila
> >< <EMAIL REMOVED> >wrote:
> >
> >> > 1. Is there any other screen reader that does make of use of these
> >> semantic hooks Word allows?
> >>
> >> You need to make sure the Defined Bookmarked Tables override verbosity
> >> setting in JAWS is set to "off" for the bookmarks to be announced.
> >>
> >> Jonathan
> >>
> >>