RE: Accessible Word Developer tools

I would second this!

 

I do use Word to create a form template that I then convert to tagged PDF
and add the form controls there. My form templates have no underline, no
symbols representing possible form controls (squares, circles and other
sometimes non-intuitive things).

 

I would add that the label/Tooltip for the Content Controls are still not
consistently identified to those of us using screen readers. They are still
keyboard traps (I was demonstrating this the other day and it took me about
10-11 tries with the keyboard to jump out of one and then my focus/cursor
was nowhere near the Content Control in the document) and any improvements
are NOT backward compatible.

 

I am using Office 365 with the latest version of my screen reader.

 

The ActivX/Legacy form controls require parts of the document to be
protected which means they are not accessible to those of us using screen
readers or Text-to-Speech tools. I've also noticed in the past year or year
and a half that even protecting parts of the Word document and forcing focus
to the ActiveX/legacy form controls does not result in a correct Tab Order
and more often than not the Word document crashes even on single page forms.

 

HTML or PDF are the best formats for forms.oh, and InDesign to an accessible
format as well.

 

Cheers, Karen

 

From: Steve Green <steve.green@testpartners.co.uk> 
Sent: Wednesday, November 10, 2021 11:46 AM
To: Siegman, Tzviya <tsiegman@wiley.com>; w3c-wai-ig@w3.org
Cc: Swedeski, Denise <dswedeski@wiley.com>
Subject: RE: Accessible Word Developer tools

 

I have recently done a lot of testing of form controls in Word documents. My
advice in the strongest terms is that you do not create forms in Word. If
you cannot produce your forms as HTML, then create PDFs, ideally from
InDesign. Word is a very bad starting point, whether you intend to
distribute the Word documents or convert them to PDF. However, if it
absolutely has to be Word.

 

Word provides three types of form control, known as Content Control, ActiveX
and Legacy. They are all horrible, but in different ways. Content Control
items are the newest type and are slightly less horrible, so you should use
those. Don't even think about using the ActiveX and Legacy controls.

 

The good news is that Content Control items support some of the basic
accessibility requirements, such as receiving focus and providing an
accessible name (which you do by adding a Title in the Properties dialog).
You cannot programmatically associate a text label with a form control.
There is no more good news.

 

There is plenty of bad news, though. For instance:

 

*	Keyboard navigation is painful. There are two ways to navigate:

*	Method 1 uses the "arrow" keys, in which case the focus or caret
(depending on whether the content is focusable or not) should move into all
content. However, it is very slow to navigate this way.
*	Method 2 uses the "arrow" keys to navigate to the first focusable
element, then uses the Tab key to navigate to each subsequent focusable
element. This is much more efficient. However, I have seen some peculiar
behaviour, such as the focus moving into the paragraph text for no apparent
reason, or some form controls not receiving focus even though they are
identical to others that do.

*	The Content Control date picker cannot be opened using a screen
reader, so it is necessary to type in the date. People using keyboard
controls can open it using Alt+DownArrow.

 

*	The Content Control combobox cannot be opened using a screen reader
and there is no workaround. People using keyboard controls can open it using
Alt+DownArrow.

 

*	The Content Control date picker does not enlarge when you zoom the
document, either in Print Layout or Web Layout. However, it should be
possible to type-in the date manually, so this is not a WCAG
non-conformance.

 

*	The dropdown lists in Content Control comboboxes do not enlarge
either. There is no workaround, so this is a WCAG non-conformance.

 

*	Checkboxes are hideous for screen reader users, and there appears to
be much more content than there actually is. When using the "right arrow"
key to navigate, JAWS 2021 reads:

*	The checkbox title.
*	The checkbox title (again) followed by "checkbox not checked", then
"ballot box checkbox content control not checked". This appears to be
because the Unicode character for the checkbox is called Ballot Box - see
https://www.compart.com/en/unicode/U+2611
*	The checkbox title (again!).
*	"Out of form field".
*	The visible text label.

Note that JAWS reads this content differently in reverse. It also sometimes
reads it forwards a little differently - I think it depends on what you were
doing previously.

 

Steve Green

Managing Director

Test Partners Ltd

 

 

From: Siegman, Tzviya <tsiegman@wiley.com <mailto:tsiegman@wiley.com> > 
Sent: 10 November 2021 14:20
To: w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> 
Cc: Swedeski, Denise <dswedeski@wiley.com <mailto:dswedeski@wiley.com> >
Subject: Accessible Word Developer tools

 

Is anyone here familiar with making Word documents that have features from
Developer tools accessible? I am working on making legal contracts and
templates accessible. I am especially interested in the following functions:

 

*	Date (both as a fill-in-the blank and a drop-down)
*	General fill-in-the-blank (e.g., company name, title, address, etc)
*	Drop-down (e.g., picking an option from a list)
*	Electronic Signatures

 

Thanks,

Tzviya

 

Tzviya Siegman

Information Standards Principal

Wiley

201-748-6884

 <mailto:tsiegman@wiley.com> tsiegman@wiley.com