Apache OpenOffice (AOO) Bugzilla – Issue 87784
[a11y] Users should be able to exit and re-enter form fields easily via the keyboard
Last modified: 2013-08-07 14:44:07 UTC
Steps to reproduce: 1. In the Options dialog, under Accessibility, check the "Use text selection cursor in read-only text documents" checkbox. 2. Open the first sample document (to be attached). 3. Use the arrow keys to move line by line from the top of the document to the first form field (this is what a user who is blind would do to access the text that precedes the first form field). 4. Move focus to the first form field by pressing Control+F5. 5. Fill out this field and use Tab to move to the next field. Fill out the next two fields in a similar fashion. 6. Note that there is some text that follows the Street Address text field that someone who is filling out this form might need to read before proceeding. A user who is blind will need to rely upon the "text selection" cursor in order to access this text, which means that he or she will need some way to easily exit the Street Address field and continue moving downward. Expected results: There would be a keyboard command with this functionality. Actual results: There does not seem to be such a command -- not one that I can find documented anywhere (help, customize dialog). 7. Ignore the issue raised in 6 and use the mouse to click on the text "More Stuff We Need to Know" thus re-enabling the text selection cursor. (If you cannot use a mouse, I did make "More Stuff We Need to Know" a heading, so you can accomplish this step via OOo's Navigator.) 8. Having exited the active form field, arrow through the lines of text. Then continue filling out the form by moving focus to the next form field. Expected results: There would be a keyboard command to move focus to the next (i.e. with respect to the present caret location) form field. Actual results: There doesn't seem to be such a command (that I can find). * Shift+F4 moves to the next group (which in this case was made to coincide with the next form field), but how can one activate the group having moved there? Does such a command exist? * Tab doesn't work. * One *could* (one must?) press Control+F5 to move focus back to the first form field followed by Tab to move past all the fields you've already filled out. But this is not ideal (and will progressively take longer and longer as one works his/her way through the form). BUT: * Mouse users can click on the desired radio button. 9. Continue filling out the remainder of the form, being sure to use the caret to access the instructions that follow the list of days. (Note that this time there is no heading one can access via the Navigator, nor a group one can move to with Shift+F4 -- even if there is some keyboard way to give that group focus).
Created attachment 52474 [details] First test case (read-only version)
Created attachment 52475 [details] version 2 of the test case (NOT read-only)
I just attached a second version of the test case. That version is not write-protected. Because it is not write-protected a user who is blind *could* do the following: 1. Be sure the Form Design toolbar is showing. 2. Each and every time he/she wants to exit the form: a. Press F6 repeatedly until that toolbar has focus b. Arrow to the Design Mode On/Off button and press it c. Arrow within the document to read the instructions d. Press F6 repeatedly to get back to the Form Design toolbar. e. Arrow to the Design Mode On/Off button and press it BUT: * There's still no good way (again, that I can find) to give focus to the *next* form field in order having performed the above steps. * When Design Mode is toggled, the caret seems to be (re)positioned wherever it last was within the document (i.e. so there's no reliable way -- that I can find -- to move the caret to the *next* bit of text.) * That's an awful lot of extra steps one has to perform simply because one cannot use a mouse. * Performing those steps means the user might accidentally alter the form itself (e.g. move fields around, delete them, etc.) -- and is more likely to not realize that this has taken place due to a visual impairment. So obtaining (or creating) an unprotected copy really is not the solution IMHO. In order for users who are blind to fill out forms in Writer documents we really need an easy (and intuitive, and well-documented) way to use the keyboard to accomplish the focus changes mouse users can accomplish with a mere click. Thanks in advance!!
Well, the problem is that those kind of documents have 2 element structures: - the form - the text flow Indeed the navigation between those structures is not easy. Imagine having a document with frames and Draw object and I can imagine that navigating with the keyboard becomes pretty impossible... Implementing 1 consistent keyboard navigation for such heterogeneous documents would require - I guess - to rethink the Write structure -> not sure we have resources for that. As I already mentioned in a previous issue (sorry, I don't have the ID!), the document author can try to make this document itself as accessible as possible, if Writer doesn't offer all possible navigation features. In this case, I'll attach an "full form" version of the sample document. In this accessible version, every field can be accessed using (Shift+)Tab.
Created attachment 52622 [details] accessible document
@OBR: maybe we can find a mid solution implementing new shortcuts?
A "mid solution" would be most appreciated as I don't think we can count on folks knowing all of the strategies for making a 100% accessible form (or even knowing that there are potentially accessibility issues and strategies which they need to use). :-( If there's a way for y'all to add keyboard equivalents for clicking on areas with a mouse, I think we'd suddenly have a lot more "accessible" forms out there. Thanks!!
The MacOS X build in screen-reader VoiceOver has it's own shortcuts for moving inside a document. I briefly thought about whether a similar feature for Orca might be helpful, but this would require that Orca had full access to how content flows: The form fields are exposed by OO as children of a paragraph, but there are no flows_from / flows_to relationships of these paragraphs with the other ones in the document. But this is more Malte's area of expertise ..
Having access to how the content flows would be cool independent of this issue. :-) And perhaps once Orca had that information it could implement a feature along the lines of what you describe. That would solve things for Orca users, but it wouldn't solve things for users with a disability other than visual impairment which prevents the use of a mouse. So I'm wondering.... 1. Control+F5 seems to reliably move focus to the first form field in the document. Would it be possible for you to modify this functionality so that if the text selection cursor has been enabled Control+F5 would instead move the user to the next form field w.r.t. the location of the cursor? 2. Escape seems to be a natural "get me out of this form field" key. If the user is interacting with a form field (and by doing so has disabled the text selection cursor), could pressing Escape cause focus to be removed from the active form field and cause the text selection cursor to be re-enabled (and perhaps located just before or just after the form field in question)?
Sorry for looking into this so late - the issue was not in my (internal) "intray" for some reason. This issue is about 2 different things: 1) How to escape from a form field, back to normal text 2) How to active the "next" field when being in normal text. My suggestions: I agree with Joanie that ESC should bring you out of the filed, back to normal text. We already do it this way with drawing objects. Tricky: If a combo box as a menu open, then of course ESC should simply close the menu, but not leave the control. And: Ctrl+F5 maybe should activate the "next" field, not the first one. Could be determined/guessed via anchor position. MT->FL: UX stuff, please provide spec or advice to app developers. Changing target to 3.x.
Trackback to the Orca bug: http://bugzilla.gnome.org/show_bug.cgi?id=361737
Blocker for keyboard accessibility => OOo 3.3
Work around: F6 to remove focus from document content, ESC to go back to document text...
Please take over. Thank you.
clu->mt: i would fix it exactly like you have suggested (these are two a11y bugs that hinder fluent keyboard a11y handling). p.s. for the combo box and similar cases i would suggest to use two times ESC (one for closing menue, the other to leave the control) p.p.s. @es: maybe we should include a chapter for a11y hints like this (to only use controls in forms) in our help?
sorry, rather fs area => changed owner
not really a clean "spec" here, there's too much "should", "maybe" and the like for my taste ... Okay, using ESC is not a good idea, in my opinion. In a table control, it reverts all changes to the current row (and there's plans to possible use the same behavior for "normal" database-bound controls). Requiring to undo row changes before being able to leave the control by keyboard is not a good idea, for sure. So, we would need another key. My suggestion would be to use Ctrl-F5 as toggle key. This would solve the problem of getting out of a control. The second problem is the one of getting into the form control next to the current cursor location. In general, I think Ctrl-F5 can be used for this, too - there's no particular reason why it moves to the first control, the more since it's not the "top-most" or some such, but the first control in the logical order, which cannot even be changed by the form designer. So, the current choice where Ctrl-F5 leads to is pretty arbitrary, so we can easily change it to have some more meaning.
fixed in CWS dba33f find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba33f
fs->msc: please verify in CWS dba33f
I followed the link provided to see if this change has been integrated. Between what I see there and what I see using m77, I'm gathering it's not been. Any ETA? Thanks!
@Joanie: have a look at the CWS table summary (the link FS provided). "Milestone (integrated)" is empty and the status of the CWS is "Ready for QA". You will be able to test this when the status will be "Integrated" and "Milestone (integrated)" filled with a milestone number.
I wrote a followup issue 111870. In some special cases not the next/nearest control is selected. verified in CWS dba33f find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba33f
Closing accessibility issues which have been fixed, verified and integrated...