WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WebAIM-Forum Digest, Vol 54, Issue 8

for

From: ejp10
Date: Sep 9, 2009 1:40PM

> ejp10 wrote:
>
>> Welcome to my favorite black hole in the standards.
>
> There's really no hole, regarding the accessibility of "special"
> characters. It's just unstandardized. (There are really no
> _standards_ on accessibility, unlike on character code, and the
> various "recommendations" and "guidelines" are mostly very silent
> about "special" character issues.)

That's why it's a black hole. Many accessibility checkers and tools in
the U.S. seem to be assuming an English-only or Western European only
environment.

>
>> For the record,
>> the problem isn't Unicode, but lack of Unicode support on JAWS.

For users of screenreaders such as JAWS (which was what was in
questions), it is a lack of support for upper level Unicode characters
in that there is no default mechanism for interpreting the glyph into
an an comprehensible alternative.

From what the original poster was writing, the characters were read
with their numeric code points only, and as confusing as some glyph
names may be...it must be better than hearing a set of numbers.

If Microsoft or Apple stopped supplying fonts to support upper level
glyphs...who would the Unicode community criticize?


>
>
>> Another thing to be careful of is to NOT use the Microsoft Word
>> Insert
>> palette. That often inserts non-Unicode material.
>
> I'd say "sometimes" rather than "often". If you don't use Wingdings
> or other fancy fonts and don't insert special controls (like line
> break controls), you normally get a real Unicode character.
>

Personally, I have encountered problems inserting mathematical
characters with Times New Roman using the Word Insert Symbol tool.
That tool does default to the Private Use Area.
http://www.personal.psu.edu/ejp10/blogs/gotunicode/2008/03/micrsoft-word-logic-inserting.html

I often recommend Arial Unicode MS and to use the Character Map (Win)
or Character Palette (Mac)

Elizabeth

> --
> Yucca, http://www.cs.tut.fi/~jkorpela/
>
>
>
>
> From: "Waltenberger, Lon (LNI)" < <EMAIL REMOVED> >
> Date: September 8, 2009 4:58:37 PM EDT
> To: "WebAIM Discussion List" < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Pagemaker or QuarkXPress and Accessible PDF
> Document
> Reply-To: WebAIM Discussion List < <EMAIL REMOVED> >
>
>
> Hi Randy,
>
> Forgive me if I talk about stuff you already know.
>
> Creating accessible PDFs from InDesign and other graphic-oriented
> applications is difficult at best and usually impossible.
>
> Find more info about accessibility using InDesign at
> http://www.adobe.com/accessibility/products/indesign/.
>
> I agree with Steve Green for the most part.
>
> PageMaker was not designed with accessibility in mind. Adobe alludes
> to
> that if not directly states it on their site.
>
> I can't speak to QuarkXpress but assume accessibility non-existent
> because it too is designed to create products for print media only.
>
> The best way to make PDFs accessible is to ensure the original
> document
> is properly structured. Few understand the importance of this or know
> how to accomplish it. It isn't difficult; it's merely a new way of
> doing
> things.
>
> For Microsoft Word, here's a start from Adobe at
> http://blogs.adobe.com/accessibility/2008/03/reference_card_for_accessib
> le.html.
>
> Please know that neither Acrobat's Quick/Full Accessibility Checker
> nor
> the Read Out Loud voice synthesizer can be trusted.
>
> The checker does its best (kudos to Adobe for all of their work on
> accessibility) but it's machine-based. It'll tell you that the PDF has
> no problems because it sees tags throughout the PDF. However, the tags
> could be, and probably are, scattered about the PDF in anything but
> readable order.
>
> Most of the time, from experience and reading it on Adobe's site, it's
> best to remove the programmatically placed tags and manually tag the
> document. Only knowledgeable human eyes can create accessible PDFs.
>
> The Read Out Loud functionality is okay but it's not a robust screen
> reader. According to Adobe it's about 90% as efficient as JAWS. Which
> 10% do you want to leave unknown?
>
> The only true test of a document's accessibility for screen readers is
> to visually follow a screen reader through the document. This ensures
> complete coverage in logical reading order.
>
> Freedom Scientific's EULA forbids using the JAWS demo for testing. I
> find that disappointing.
>
> GW Micro at http://www.gwmicro.com/ allows use of the Window-Eyes demo
> for unlimited testing. They have a 30-minute limit that requires a
> reboot to continue using. I applaud their generosity for testing but
> 30
> minutes go by quickly until one becomes proficient using Window-Eyes.
>
> NonVisual Desktop Access (NVDA) at http://www.nvda-project.org/ has a
> free robust open source screen reader. Check out the flash drive
> version. It runs from a thumb drive on any PC with a simple file
> download. This is great for demonstrating screen readers to content
> owners. You can add Microsoft Mike and Mary for a better audio
> experience. And there's no time limit. Additionally, Adobe recently
> announced support for NVDA's reader at
> http://blogs.adobe.com/accessibility/2009/08/adobe_supports_open-source_
> nvda.html.
>
> I hope you find some of this useful.
>
>