GNOME Bugzilla – Bug 133275
accessible description for page not correct.
Last modified: 2008-07-22 19:33:31 UTC
In gedit application, file menu > print preview. In print preview window,, page number, 1 of 6, screen reader reads it as page simple text, it will not read the page numer. For ex : page : 1 or page page of 6 etc. Expected: Screen reader should read complete line along with lable. For ex; “ page: 2 of 6 “
Transferring to gnopernicus for evaluation.
Loocking at at-poke, there are no relations between the spin button and the two labels ('of' and 'Page total'). But we usually need a LABEL_FOR/LABELED_BY relation between an object and a single label. In this case, we have that relation (see the 'Page:' label). In my opinion this is not an usual situation, so it has to be solved as a special-case. Even if we have these relations I don't know how we shold report the required description. This problem is the same with the one described in bug 135366. I think the only solution for this problem is scripting. Any other ideas?
It's not unusual for LABEL_FOR/LABELLED_BY to apply to multiple objects, or for an object to have multiple labels. LABEL_FOR/LABELLED_BY are both potentially many-to-many relations. Can we fix this by creating somewhat more detailed RELATIONS in this UI?
The text "of" and "6" are in separate labels. Even if we did create label-for/labell-edby relations it probably would not be spoken in the correct order. Even if we get the labels in the correct order we would get "Page of 6 1" or "1 Page of 6" depending on whether the labels are spoken before or after the name.
making the text labels for the page number and the word "of" separate labels is definitely an a11y bug. I'm sure it's probably an i18n bug too... adding I18N keyword.
*** This bug has been marked as a duplicate of 111854 ***
Peopen, because this is not a duplicate of 11854.
I think the best behavior here would be to make "Page n of m" into a single label, possibly one which uses markup or manipulation of its internal PangoLayout to create the desired visual effect. I think we may need ngettext or something similar in order to correctly translate such a string; in any case I think the string marked for translation needs to be something other than "page", "of", etc. From there we can composite the correct label text. Doing this with multiple labels works OK in english (if you're not using a screenreader), but I think the "right fix" for gnopernicus and for i18n is something like the above suggestion.
Bill : Making it into a single label is not feasible. The <n> in 'page <n> of <m>' is _editable_
right. but how does one create a properly-localizable interface of this sort (i.e. a numeric spinbutton embedded in a translatable string)? The multi-label approach is broken for a11y in much the same way as for i18n since the AT doesn't know what order the the labels should appear in.
I guess - to be more clear - I am suggesting that "page <spinbutton> of n" may not be a good UI from a HIG + i18n POV. I think we should solicit feedback from usability and i18n on this (probably this happens throughout GNOME, and needs to be addressed in the HIG).
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Did anything happen with this the last two years?
Transferring to Orca. It's trivial to workaround this by adding a section of code to the Orca gedit.py script.
Created attachment 104044 [details] [review] Revision #1 Patch to work around the problem. If we are doing a Print Preview and we are focused on the page number text area, also speak the "of n" labels to the right of this area. Please test.
This seems OK (thanks!). Comment #4 demonstrates the problems we run into when trying to solve this in the general case. Another example of this is the "Scrolling" tab of the gnome-terminal preferences dialog. On that tab, the "Scrollback" spin buttons essentially have two labels -- the "Scrollback" label and the units ("lines" and "kilobytes"). default.py:getDisplayedLabel and default.py:findDisplayedLabel are kind of the beginnings of being able to support the multiple-label problem, but they currently do not provide any label/obj ordering support at this point. We currently just present the labels in the linear order in which we found them followed by the object. This algorithm doesn't handle the case where the object info should be presented before the label. We could potentially open an RFE to handle the notion of the order in which to present objects and their labels, but I think we could also probably just custom script for now until the use case(s) go beyond this particular problem and the gnome-terminal problem. The only comment I have for now is that we also need to make sure brailled is addressed. :-) Thanks!
Created attachment 104566 [details] [review] Revision #2 This version adds in the braille equivalent, but the problem is that it puts them right at the end of the braille line. I.e: BRAILLE LINE: 'gedit Application Unsaved Document 1 - gedit Frame TabList Unsaved Document 1 Page ToolBar 1 $l of 1' There doesn't seem to be any existing API in the Line class in braille.py to allow me to add them "one in" from the end of the line. One possibility is to add a new parameter to the addRegions() method giving the position to append the region (default being to always append it at the end). We are past the API freeze for GNOME 2.22 though. Suggestions on how to fix this would be most appreciated.
Created attachment 104568 [details] [review] Revision #3 The changes needed to be in locusOfFocusChanged() rather than onStateChanged(). There is still the concern of the "of N" being appended to the braille line after the "$l". I did try replacing: line.addRegion(braille.Region(" " + label1)) line.addRegion(braille.Region(" " + label2)) with: length = len(line.regions) line.regions.insert(length-1, braille.Region(" " + label1)) line.regions.insert(length-1, braille.Region(" " + label2)) but the problem there is that the last region on the braille line before I try to insert two new ones just before the end, appears to be "1 $l". I would have expected that to have been two regions. Maybe this is one of those cases where it's just better to only try to improve the situation for speech...
Created attachment 104580 [details] [review] lose the $l (proof of concept) > onStateChanged(). There is still the concern of the "of N" being > appended to the braille line after the "$l". I'm not convinced this is a concern. The "$l" is the end of line indicator for a text region (right??). As such, I personally think it should stay as you have it as an indicator to the user that "the text ends here, and by the way, there's this 'of N' bit at the end." :-) But if you want the $l gone... You can create a custom braillegenerator that creates a text region sans the EOL indicator. Attached for demonstration purposes (because I think your current patch is correct. :-) ) Sounds like a question for Mike.
> Sounds like a question for Mike. Yes is does. Thanks Joanie. Mike?
I'd prefer to leave the "$l" here for the reason Joanie states.
Thanks Mike. I've obsoleted Joanie's patch. Did my third revision: http://bugzilla.gnome.org/attachment.cgi?id=104568 work for you?
seems fine. thanks
I think this looks fine. The only oddity I notice is that the "of n" text disappears when I type in the text area. I think this is acceptable if Mike thinks it is acceptable. However, Perhaps we should open an RFE along the lines of the comments at the end of comment #17? What do you guys think?
This is OK with me because once you start typing text it is pretty obvious what you are doing and the text field needs to expand on the display as you are typing any way.
Revision #3 of the patch committed. I'll leave it to Mike to answer your question about the suggested RFE. Moving to "[pending]".
I think the RFE is a good idea.
Thanks for the verification Mike. Closing as FIXED. I'm going to leave it to Will to open the RFE based on the last lines in comment #17 because I'm not sure I fully understand it.
(In reply to comment #29) > Thanks for the verification Mike. Closing as FIXED. I'm going to leave > it to Will to open the RFE based on the last lines in comment #17 > because I'm not sure I fully understand it. > See bug 516120.