Community
Participate
Working Groups
A number of accessibility tests with screen reader users in IBM have submitted comments that the hidden frames are severely impacting the usability for screen reader users in the following way: - A number of hidden frames are used 'together'. Because the screen readers voice the text for the hidden frames, the users hear a series of "Ignore this XYZ frame, it only contains other frames. Ignore this ABC frame, it only contains other frames. Ignore this DEF frame, it only contains other frames." before the voicing starts for a real, visible frame. This makes for a lot of text read in a row that makes it hard for the screen reader user to distinguish the title and purpose for the visible frame that they can work with. Some suggestions the accessibility testing teams submitted for alleviating this problem for screen reader users: 1. Make the text more concise. Instead of "Ignore this ABC frame, it only contains other frames.", use "Hidden layout frame". That will get across the message that the frame is hidden, and is shorter so that when it is read multiple times to the user, the elapsed time is faster. 2. Provide a hotkey to jump directly from the navigation frames to the topic content frame. Perhaps such a hotkey exists and we haven't observed it? As comments are coming in from various accessibility testing teams about the impact this is having in their tests with screen reader test subjects, it would be very important to at least get a shorter text string for Version 3. --Lee Anne
1. There are hidden frames, in help, but I think you do not notice them. The frames you describe are not hidden, "they only contain other frames". For example there is frame A that contains frame B and C. Frame B is a view toolbar, frame C is the view content. Frame A is not hidden, otherwise the embedded frames B and C would be hidden. Saying that the frame are hidden is not true, and might lead to confusion, their content (content of embedded frames) is important. All these frames (containing other frames) are configured not to take focus, and JAWS correctly ignores them. For readers that do not ignore them automaically the text provides enough information, and starts with the word "Ignore", so user does not have to listen to the full description. We cannot shorten the text as you suggest, since some readers require frame names to be unique, that is why the text includes the frame name. I think we can say "Layout frame ABC." Is it better? 2. In a browser, Ctrl+ Tab,Tab,Tab. I think Jaws has a shortcut to display the frame list, and then any frame can be selected (so 2 shortucts gets you there).
Changed Ignore this ABC frame, it only contains other frames. to Layout frame: ABC
Lee Anne, Is there anything else to be done in this bug, or can we close it?
2. Added ALT-K to set focus on content frame. It is not on the document as it is not authored by help and is constantly changing when user browser. Hence pressing ALT-K does not focus on anything inside the viewed document, but next press of the TAB does. Marking as fixed.
Hi Konrad, I apologize for the delay. I was out sick last week. Thanks for the explanation re these not really being hidden. That was my own misconception of how the frames related to each other. On #1, yes, "Layout frame ABC" is better. They were asking for shorter sentences in the tests with users, because for each contained frame, the voicing repeats. On #2, you wrote "Added ALT-K to set focus on content frame. It is not on the document as it is not authored by help and is constantly changing when user browser." I don't quite understand that sentence "It is not on the document as it is not authored by help and is constantly changing when user browser." Do you mean that ALT-K will only be for certain browsers (e.g. IE?)? That is all right if it is only for IE. The accessibility guidelines tell us that as long as one configuration has the function (e.g., JAWS and IE on Windows, or JAWS and Mozilla on Windows), then we are in compliance. What does "not on the document" mean? And "not authored by help"? So, for #2, is the result that the screen reader users would press ALT-K to go immediately to the content pane, and then press TAB to then get focus on the topic in the content pane? Thanks! --Lee Anne
Keyboard shortcut is defined in the target element (the one that will receive the FOCUS when given combination is pressed. It would be very difficult (for us - help system) to ensure that documents for each topic define the shortcut. If they did, the shortcut might not work until the document is fully loaded. The topics changes when user uses help, so there are periods when there is nothing valid inside the content frame. As help system developers we have no control of how HTML of individual topic look. It might not have a BODY element - be PDF or frameset or sth else. Trying to set focus on something inside such topic document would not work. So a doable solution is to define the shortcut on the element, higher in the hierarchy, that is always there. The closest is the <FRAME> element that will load topic documents. And this is how it works in IE: Pressing Alt-K takes focus to (not into) the content frame <FRAME>. If user presses Tab, the next focusable element is (inside the frame) - <BODY> of the currently loaded topic. At this point user can read/scroll document. In case document contains focusable elements (links), pressing Tab more times takes focus from the body through these links. As for browser support, Not everything that works in IE works in Mozilla, and ALT-K for setting a focus on a frame is one of the things that does not work the same - nothing happens on Mozilla. If screen reader reads IE, it will work, if it is used to read Mozilla it will not.
OK, I understand about the doable solution being to put the shortcut to something that is always there. More stable that way, and stability is always good. :-) So, ALT-K will put the focus on the frame that'll load the topic and then TAB will put focus on the <BODY> and the user can read. Sounds good to me, thanks!
