GNOME Bugzilla – Bug 517728
Need to consider better handling of objects of ROLE_TEXT in FF3
Last modified: 2015-05-28 03:20:41 UTC
Please describe the problem: when html documents contain abbr tags, we seem to say "text" after the abbriviation. i.e. <abbr title="et cetera">foobar</abbr> we speak: "foobar text" Assuming design consistancy the presentation should be: "foobar abbriviation" further consistancy: If the abbriviation has the focus, orca-whereAmI should present the title property, just like what we do with other tool-tip texts. Currently whereAmI speaks "foobar text" (issue noticed on account page of www.lloydstsb.com) Steps to reproduce: Actual results: Expected results: Does this happen every time? yes Other information:
The reason we speak "text" rather than "abbreviation" is because text contained in an abbr tag is exposed to us as being of ROLE_TEXT. There is no ROLE_ABBREVIATION (that I'm aware of anyway). So we're just passing that role info on to you. Mike I need your input here: Should we be speaking abbreviation, should we be displaying that in braille? As for the speaking of the title, I'm going to tack that on to the whereAmI paragraph bug you filed. It's not a dup, but it's closely related.
Does this mean that text input fields and abbriviations return the same role object? if so, Isnt that a bit a bit curious?
(In reply to comment #2) > Does this mean that text input fields and abbriviations return the same role > object? Nope. Well, not in Firefox anyway. In other applications, text input fields seem to have ROLE_TEXT. In Firefox, text input fields have ROLE_ENTRY and various and sundry other things have ROLE_TEXT. For instance, I think that I once saw a table row exposed as ROLE_TEXT. Mind you table rows aren't normally exposed as objects at all, but there was something special about the markup on the page in question.... As part of this bug/RFE, I'm going to start looking for all the things that are exposed as having ROLE_TEXT and noting what their functional role is (and how that functional role can be identified). From there we can make a better decision about how we want to deal with these creatures. > if so, Isnt that a bit a bit curious? "Curious" isn't the word I'd use, but.... Sure. ;-)
(In reply to comment #3) > (In reply to comment #2) > > Does this mean that text input fields and abbriviations return the same role > > object? > Nope. Well, not in Firefox anyway. In other applications, text input fields > seem to have ROLE_TEXT. In Firefox, text input fields have ROLE_ENTRY hmm, consistancy .. consistancy. I assume its down to inconsistent definitions of these roles,leading to people using whichever role they feel most confertable with at the time. > and various and sundry other things have ROLE_TEXT. For instance, I think that I > once saw a table row exposed as ROLE_TEXT. Mind you table rows aren't normally > exposed as objects at all, but there was something special about the markup on > the page in question.... what a funky table :) (note to self, it would be intresting to see what sort of markup that one had.) > As part of this bug/RFE, I'm going to start looking for all the things that are > exposed as having ROLE_TEXT and noting what their functional role is (and how > that functional role can be identified). From there we can make a better > decision about how we want to deal with these creatures. Excellent, thank you for looking into it, sorry for adding to the workload > > if so, Isnt that a bit a bit curious? > "Curious" isn't the word I'd use, but.... Sure. ;-) :)
I'm setting the target milestone to FUTURE because providing functional roles (such as abbreviation) will require new strings.
First coarse pass at GNOME 2.24 planning.
As discussed in team meeting, this is an enhancement. Reclassing as such.
I hope this is the correct place my problem. Sometime when I read a webpage with Orca, Orca says non existing editbox controls. For example the following webpage have lot of new comments, if I navigate the new comment (contains új word), Orca says editbox with end of the string, but not existing any editbox with this webpage: http://ubuntu.hu/node/11081 If I navigate for example the "rudi – október 25. 15.31 Új " string, I hear the non existing editbox with end of this string. But another place with I always see this problem with bugzilla.gnome.org, for example I always hear non existing edit box after the [reply] [-] link. Attila
On the additional comment I note that Gecko exposes the html element the object is related to as an object attribute like tag:ABBR Maybe the gecko script should consider the tag when deciding what to speak. Attila, your issue doesn't sound related. I can't reproduce the bugzilla issue, I hear "reply dash comment x by john doe" Which seems correct. I couldn't reproduce on the ubuntu site, but I can't speak hungarian and don't have any ubuntu accounts so....