WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible Word Docs - Need Help

for

From: Carolyn Dudas
Date: Jun 14, 2016 9:02AM

Thanks, Jon, and to everyone for their suggestions.

----------------------------------------------------------

Carolyn Dudas



> -----Original Message-----
> From: Jon Metz [mailto: <EMAIL REMOVED> ]
> Sent: Tuesday, June 14, 2016 10:54 AM
> To: WebAIM Discussion List < <EMAIL REMOVED> >; Carolyn
> Dudas < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Accessible Word Docs - Need Help
>
> Completely shameless plug here, but I made a series of videos to take a
> Word document and turn it into a PDF/UA compliant PDF
> (https://youtu.be/BeFt-
> Qa3mjM?list=PLmfVOnJxeSEXsEKv2i20nYMHYuFEcl4fO). However, you
> could ignore the last video unless there's a requirement to do that, or
> you
> need a way to validate that it works as an accessible PDF. Up to the 3rd
> video explains how to make a tagged document and make it as accessible as
> possible before going all out compliant.
>
> The first video goes through what's necessary to make the Word file as
> accessible as possible. I'd avoid adding forms in Word first before moving
> to
> PDF, because more headaches happen in the translation to PDF.
>
> I'm still getting around to editing the last video which goes over
> testing, but I
> did a short session on it for ID24 you can check out here:
> https://youtu.be/1CCQ5TGlM0I?list=PL95LOQw9SLWxmcZtzBiFuT9HAJKFJnl2
> n. Just know that in order to validate accessibility, you would have
> needed to
> suffer through all 4 of those videos.
>
> Once you're in the 3rd video, simply refer to Adobe's guidance on creating
> an accessible form in Acrobat
> (http://www.adobe.com/accessibility/products/acrobat/creating-accessible-
> forms.html) or Joseph's tutorial (which I haven't looked at yet). Hope
> this
> helps you.
>
> Cheers,
> Jon Metz
>
>
>
> On 6/10/16, 2:18 PM, "WebAIM-Forum on behalf of Morin, Gary (NIH/OD)
> [E]" < <EMAIL REMOVED> on behalf of
> <EMAIL REMOVED> > wrote:
>
> >Carolyn,
> >
> >The changes you make will also make it possible for those who are sighted
> and/but are using speech recognition software. My sense or experience is
> that online forms are the easiest to fill-in but probably much more
> involved
> on the backend, involving developers or database management, than just
> issuing Word or PDF-based forms.
> >
> >Gary
> >
> >-----Original Message-----
> >From: Tyllick,Cliff S (DADS) [mailto: <EMAIL REMOVED> ]
> >Sent: Thursday, June 09, 2016 4:59 PM
> >To: WebAIM Discussion List < <EMAIL REMOVED> >
> >Subject: Re: [WebAIM] Accessible Word Docs - Need Help
> >
> >Joe, your approach is similar to "Creating Accessible Microsoft Word
> >Forms the DARS Way":
> >http://accessibility.hhs.texas.gov/docs/word/WordFormsDARSWay.docx
> >
> >Also available on Youtube:
> >https://www.youtube.com/watch?v=oimoTFdXKLo&feature=youtu.be
> >
> >The DARS Way offers two ways around the 138-character limit.
> >
> >First, the Help Text property for a form control in Word offers two
> >fields
> for content:
> >- Status Bar has room for 138 characters. Anything entered here is
> automatically announced by the screen reader when the form control
> accepts focus.
> >- Help Key (F1) has room for another 213 characters. If this field
> >contains
> anything--even a blank space--the screen reader should announce "Press F1
> for Help" as soon as it finishes announcing the contents of the Status
> Bar.
> >
> >So between those two fields, you have room for 351 characters. There is a
> bit of art to separating the information when it runs over 138, but it
> usually
> isn't hard to find a reasonable approach.
> >
> >The second method is not my favorite, but it does work for many people.
> When 351 characters isn't enough, the DARS Way is to add more text input
> controls and use their Status Bar and Help Key fields as a container for
> the
> rest of those instructions. Of course, this has a few problems:
> >- As a text input, this container will accept keystrokes. Information
> >entered
> here should get ignored, but if the user presses a key for a character, it
> will
> populate this input.
> >- You have to hide this container from people who can see.
> >
> >The DARS Way offers a simple workaround to let people who cannot see
> know that they should not enter text in this form input: start the
> contents of
> the Status Bar with "Info." This gives them a clue to ignore the "Edit"
> prompt
> announced by the screen reader after it has announced the Status Bar.
> >
> >In the DARS Way, you can hide these additional text inputs--I'll call
> >them Info fields--from the visual interface by making them narrow. In
> >the properties of the Info field, set Maximum Width to 1 character. (If
> >you set it to 0 characters, Word will skip right past the field. With
> >or without a screen reader, you won't know it's there.)
> >
> >To make the Info field become a sliver, select it and change the font
> >size to
> 1 point. (You will have to key the "1" in; the lowest you can select is 8
> point.)
> While you're in the Font interface, you can reduce the Info field to a
> pinpoint
> by making the font super- or subscript, too.
> >
> >Unfortunately, hiding the Info fields doesn't give us fewer problems. It
> >just
> changes the nature of the problem. When a document is set up to be
> completed as a form in Word, it's protected so the user can change only
> the
> content and state of the form controls. To move from field to field, you
> must
> press the tab key.
> >
> >So you open the form, and the focus is in an Info field--not "Name," or
> whatever your first actual form field is. If you start typing, you will
> see no
> change--unless your eyes are very sharp--and you will hear a beep or see a
> flash when you enter more than the maximum number of characters the
> Info field will accept.
> >
> >If there is a lot of text, you might have to press the tab key several
> >times
> before a real form input takes focus. You will have to stay alert to make
> sure
> you are always entering information in a real field--and that it's the
> right
> field.
> >
> >If you can't see well, it can be that much more frustrating to have to
> >press
> the tab more than once to skip from one field you must complete to the
> next.
> >
> >And that's why Joseph suggested you use PDF or HTML.
> >
> >Cliff
> >
> >Cliff Tyllick
> >EIR Accessibility Coordinator
> >Texas Department of Aging and Disability Services (DADS)
> >512-438-2494
> > <EMAIL REMOVED>
> >
> >
> >-----Original Message-----
> >From: WebAIM-Forum [mailto: <EMAIL REMOVED> ]
> On
> >Behalf Of Krack, Joseph@DSS
> >Sent: Thursday, June 09, 2016 1:35 PM
> >To: WebAIM Discussion List
> >Subject: Re: [WebAIM] Accessible Word Docs - Need Help
> >
> >Carolyn,
> >
> >I would recommend making this an accessible PDF form. It is possible to
> make an accessible Word form, but the limit of 138 characters in the Help
> Text would really make this impossible.
> >
> >Someone using a screen reader may hear something that is easier on the
> ear if you change the way you make the lines, but they still would be
> unable
> to fill it in. All forms can be printed and filled in by hand, and I would
> encourage that all forms be made to be accessible.
> >
> >I am working on creating a new training for creating accessible forms,
> >but when I was with the Department of Rehabilitation I put together a
> >short booklet on creating accessible forms in Word and PDF that you can
> >take a look. Please let me know if you find the booklet useful, or if
> >you have any questions.
> >(http://www.dor.ca.gov/DisabilityAccessInfo/How-do-I-Construct-Accessib
> >le-Documents.html)
> >
> >I hope this helps.
> >
> >Joe Krack
> >Manager, Accessibility and Policy Unit
> >ADA Coordinator, Department of Social Services
> >744 P Street, MS T8-4-70
> >Sacramento, CA 95814
> >(916) 651-5647 (direct)
> >
> >
> >
> >-----Original Message-----
> >From: WebAIM-Forum [mailto: <EMAIL REMOVED> ]
> On
> >Behalf Of Carolyn Dudas
> >Sent: Thursday, June 09, 2016 11:09 AM
> >To: <EMAIL REMOVED>
> >Subject: [WebAIM] Accessible Word Docs - Need Help
> >
> >I'm working with staff to help them make their Word documents
> accessible.
> >Most of the Word documents are forms which are meant to be printed and
> completed by hand. By forms, I mean that there are fields which are
> followed by what appears to be a solid line, but in actuality is just the
> underscore character repeated multiple times. For instance, there are
> fields called "First Name" and "Last Name" which are followed by a series
> of
> underscore characters. Example: First Name__________________ Last
> Name________________.
> >
> >Also, there is an essay question on the form. Again, the author
> >originally
> typed the underscore character multiple times (for a total of 9 lines) so
> that
> someone can write their response. Example:
> >"Why would you be a good candidate for this
> >program?"> >> __________
> >_____________
> >> __________
> >_____________
> >
> >To make this document accessible for a person reading it via a screen
> reader, I've advised staff to use a leader tab formatted with an
> underscore
> rather than typing the underscore multiple times. Is the leader tab the
> recommended method for creating underlines for this type of form?
> >Is this OK in terms of accessibility --- can a screen reader correctly
> >read the
> document?
> >
> >Recommendations would greatly be appreciated.
> >
> >I'd especially like if someone who is proficient in using a screen reader
> >or
> uses one daily could actually "read" my sample document to see if it's
> accessible. If you are willing to do this, please let me know offline and
> I'll
> send it to you as an attachment. Thanks.
> >
> >----------------------------------------------------------
> >Carolyn Dudas
> >> >> >archives at http://webaim.org/discussion/archives
> >> >> >> >archives at http://webaim.org/discussion/archives
> >> >> >> >archives at http://webaim.org/discussion/archives
> >