RE: Accessible Word Developer tools

Hi Christophe,

While your test results with Word 2016 are interesting, it doesn’t get any feature updates so it is 5 years out of date compared with Word 365. Accessibility support has improved substantially in that time. This is another reason not to publish forms as Word documents, because I have “professional” clients still using Word 2013 and I know people in the visual impairment community using Word 2010 and 2007.

I found the new Content Control controls to be mostly keyboard accessible in Word 365. Karen McCall described some keyboard navigation issues in her email, but I have not encountered those problems.

I agree with everything else you wrote, which reinforces why you should not use the ActiveX and Legacy controls. FWIW, you can add accessible names to ActiveX and Legacy controls, so it doesn’t matter that screen readers don’t read the visible text if you have restricted interaction. For Legacy controls, you add Help Text in the Properties dialog. For ActiveX checkboxes, you edit the Checkbox Object – I didn’t look at other form controls, but I expect they have similar objects.

Steve


From: Christophe Strobbe <strobbe@hdm-stuttgart.de>
Sent: 10 November 2021 17:30
To: w3c-wai-ig@w3.org
Subject: RE: Accessible Word Developer tools

Hi Steve,

I'm surprised about your findings about the three types of form controls in Microsoft Word. I tested form controls (in Word 2016) during the summer and I found the following:

- Only the legacy controls are (somewhat) keyboard accessible; the "newer" controls (which have been available since 2007) and the ActiveX controls are not keyboard accessible at all.
- The legacy controls don't provide a date control; you need to repurpose a text entry field for this and change the data type (and add the date format to the status bar text).
- The legacy controls don't provide a radio button, nor a drop-down list.
- Before sending out a form, you need to restrict editing so users can only fill in form fields and not modify other parts of the document.
- Restricting interaction with a document to form fields will mean that screen readers only read the "status bar text" that has been defined in the control's properties; no other content in the document will be read by default. (The visible labels next to the controls will not be read; there is no mechanism to connect the programmatically with the controls.)
- To enable access to headings, instructions etc in the document, you need to put them in section; then when you restrict editing, these sections should be excepted from the editing restrictions.
- None of the three types of form controls generate a PDF form when exporting to PDF. If you want to use a Word document as a starting point for a PDF form, it is best to leave white space rather than inserting any of Word's form controls. The form controls can then be added in Adobe Acrobat Pro. This is a cumbersome process. (So far, I have not created forms starting from InDesign documents.)

Best regards,

Christophe Strobbe

On 10 November 2021 at 17:46 Steve Green <steve.green@testpartners.co.uk<mailto:steve.green@testpartners.co.uk>> wrote:

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

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