Open
Bug 340809
(textattra11y)
Opened 19 years ago
Updated 2 years ago
[meta] Text formatting not exposed to screen readers, inaccessible
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
NEW
People
(Reporter: aaronlev, Unassigned)
References
(Depends on 6 open bugs, Blocks 2 open bugs)
Details
(Keywords: access, meta, Whiteboard: orca:normal)
ATK now allows us to expose meaningful semantics via object attributes.
The object attribute must never have a colon in it, we should use a "." instead.
We should expose:
tag=[tagname] or tag=namespaceabbrev:value (if namespace different from parent)
css.property=value
dom.attributename=value or dom.namespaceabbrev.attributename=value (if namespace different from tag)
headlinglevel=#
namespaceabbrev can be:
"html", "svg", "xul", "mathml", "xhtml2", "aaa", or "xforms"
otherwise we will have to expose the namespace URI for that, without any colons in it :(
Reporter | ||
Comment 1•19 years ago
|
||
Correct, for tag names, let's always include the namespace abbrev ad always use the "." instead of the ":"
so always
tag=nasmespaceabbrev.tagname
Reporter | ||
Comment 2•19 years ago
|
||
Also, CSS attributes should only be exposed if different from parent. Will also be used for text run attributes.
Reporter | ||
Comment 3•19 years ago
|
||
This can be done in nsAccessibleWrap.
Reporter | ||
Comment 4•19 years ago
|
||
The ATKText attributes come via GetAttributeRange(). We just need to turn the CSS for the given accessible into an AttributeSet.
Summary: New ATK: Implement AtkObject attributes → New ATK: Implement AtkObject and AtkText attributes
Reporter | ||
Updated•19 years ago
|
Assignee: nobody → gaomingcn
Reporter | ||
Comment 5•19 years ago
|
||
Also expose heading level=n
and for static text, static=true
Reporter | ||
Comment 6•19 years ago
|
||
Marking dependent on the simpler bug to just expose tag name and heading level.
Depends on: 342288
Summary: New ATK: Implement AtkObject and AtkText attributes → New ATK: Implement all AtkObject and AtkText attributes
Reporter | ||
Updated•19 years ago
|
Whiteboard: Need more specifics on what to expose or not expose
Reporter | ||
Comment 7•18 years ago
|
||
Actually I no longer want to expose all DOM attributes and all CSS properties, just targeted ones.
Will file a separate bug for dealing with text formatting.
Reporter | ||
Comment 8•18 years ago
|
||
We need to finalize a plan before continuing. Here's a wiki page for that:
http://wiki.mozilla.org/Accessibility/Attributes#Proposed_AT-SPI_Attribute_Support
Reporter | ||
Updated•18 years ago
|
Assignee: gaomingcn → aaronleventhal
Reporter | ||
Updated•18 years ago
|
Comment 9•18 years ago
|
||
(In reply to comment #8)
> We need to finalize a plan before continuing. Here's a wiki page for that:
> http://wiki.mozilla.org/Accessibility/Attributes#Proposed_AT-SPI_Attribute_Support
>
Hi Aaron. What's the status of this? We've had a user ask about access to attribute information.
Thanks!!
Reporter | ||
Comment 10•18 years ago
|
||
I'd like to have this implemented by mid-June for sure. We want to stabilize what we have first, and fix some other really bad bugs, before taking on something new.
Reporter | ||
Comment 11•18 years ago
|
||
1. We are basically done with object and document attributes, so this bug is just for text attributes now
2. We need to support what is at http://wiki.mozilla.org/Accessibility/Attributes
3. I don't see something listed for subscript/superscript -- need to investigate what Open Office does for that.
4. Please look over what it says for default attributes column -- I wasn't sure if all text attributes can also be a default attribute, and vice versa
5. Don't forget to update http://developer.mozilla.org/en/docs/Accessibility/ATSPI_Support
Assignee: aaronleventhal → ginn.chen
Summary: New ATK: Implement all AtkObject and AtkText attributes → New ATK: Implement all text attributes for ATK and IA2
Reporter | ||
Comment 12•18 years ago
|
||
More questions regarding default text attributes:
* How/why are they useful?
* They're not in IA2 -- what functionality will IA2 clients miss since it's not there? Or is there another way to emulate default text attributes
* What does Open Office use default text attributes for?
Comment 13•18 years ago
|
||
(In reply to comment #12)
I think there are two reasons/cases for caring about text attributes:
1. You want/need to know exactly how a given bit of text is formatted because you care about its appearance. (duh! :-) )
2. You want to quickly scan over a document to get an overview of its structure and/or locate important sections -- and one way to do that is to find the text whose formatting does not match the surrounding text. For example if the text in the entire document is bold, italic, and pink, those attributes are not interesting/meaningful/significant. On the other hand, if the entire document has more conventional formatting, the appearance of the aforementioned attributes is indeed interesting/meaningful/significant.
> * How/why are they useful?
> * They're not in IA2 -- what functionality will IA2 clients miss
> since it's not there?
The ability to address case 2 efficiently. If the "special" formatting is all that is exposed for the character's attributes, an AT could quickly query that. (For case 1, the AT would need to combine the default attributes with the current character's attributes.)
If *all* attributes (i.e. even the "inherited" ones) that apply to a given character are exposed as that character's attributes, AT has quite a bit more work to do for case 2: In order to identify if the current character is "special", the AT would have to compare all of its attributes with all of the attributes from something else, be it another character or a pre-defined set of attributes.
> * What does Open Office use default text attributes for?
I'm *pretty* sure that there the default attributes are those that apply to all of the text in the current paragraph, which to me is not ideal. Often "special" formatting applies to an entire paragraph (such as documents in which a section is delineated by a single-line paragraph which is bold and in larger font).
Reporter | ||
Comment 14•18 years ago
|
||
Ginn, Pete Brunet is working on a doc for IA2 to try and standardize text attributes between various applications. Of course we want to have the same text attributes between ATK and Mozilla.
You can take a look -- Pete is planning to add recommendations for restrictions on units and format, etc.
http://www.linux-foundation.org/en/Accessibility/IAccessible2/TextAttributes
Reporter | ||
Comment 15•17 years ago
|
||
Note that CAccessibleText::get_attributes() (which is for text attributes) incorrectly calls IAccessible2:get_attributes() (which is for object attributes)
Reporter | ||
Updated•17 years ago
|
Whiteboard: Need more specifics on what to expose or not expose → orca:normal
Reporter | ||
Updated•17 years ago
|
Assignee: ginn.chen → surkov.alexander
Reporter | ||
Comment 16•17 years ago
|
||
Surkov, want to work on this? Work with Marco and Ginn and have it tested a lot. It's pretty crucial for web app and Thunderbird a11y.
I think we're in good enough shape on the other stuff to look at this.
Keywords: sec508
Summary: New ATK: Implement all text attributes for ATK and IA2 → Text formatting not exposed to screen readers, inaccessible
Reporter | ||
Updated•17 years ago
|
Blocks: fox3access
Comment 17•17 years ago
|
||
I do not get about out arguments startOffset and endOffset of a range we returns attributes for. Are they minimal offsets amoung of all offsets for each attribute? If so then I think it should be hard enough to calculate them and I'm not sure if it's needed at all. It's probably better to return all attributes for the given point but to provide new method to get offsets for specified attribute. What do you think?
Reporter | ||
Comment 18•17 years ago
|
||
Surkov, for some reason I'm not understanding what you mean. Are you talking about just changing nsIAccessibleText?
Whatever makes sense in terms of implementing the right thing to AtkText and IAccessibleText.
One thing we're still deciding is whether for each accessible text, to expose all the text attributes it has or just the ones that have changed. I'm currently discussing this with AT vendors.
So, as you look at this right now be prepared that the decision could still go either way.
Comment 19•17 years ago
|
||
Let see an example
color:red
| |
some text some text
| |
bgcolor:green
IA2 propose:
[propget] HRESULT attributes
(
[in] long offset,
[out] long *startOffset,
[out] long *endOffset,
[out, retval] BSTR *textAttributes
);
What should start and end offsets be if I expose two attributes color and background-color?
If we would expose only last changed attribute then do we have an event for this?
Comment 20•17 years ago
|
||
btw, is "misspelling" attribute from bug 345759 is going to be official text attribute?
We won't support text attributes from ODF, isn't there an analgue used in gecko?
If we will expose only last changed attribute then do we have a way to watch what was changed, for example, if style rule has been applied then do we able to get notification for each rule item separetely?
Reporter | ||
Comment 21•17 years ago
|
||
Surkov: about change events -- we should think of what the use cases are for that. For Firefox 3, I think it would be good enough if text attribute change events were only fired for misspellings. That is the most likely text attribute to change where the user wasn't expecting it already. It would be good to get other's thoughts on that.
AFAIK, ODF does not expose a semantic attribute for misspellings. They might indicate that there is a red underline, but that is not really useful. I suggest we simply go with something like misspelling=true. It is the most useful for screen readers.
Reporter | ||
Updated•17 years ago
|
Assignee: surkov.alexander → aaronleventhal
Component: Disability Access → Disability Access APIs
OS: Linux → All
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Hardware: PC → All
Comment 22•17 years ago
|
||
Ok, let start from support of misspelling attribute, what's about startOffset and endOffset, should I care?
Comment 23•16 years ago
|
||
Silly question: I'm catching up on my bugzilla mail and was notified of this new bug "[Bug 445513] New: Support BOUNDARY_ATTRIBUTE_RANGE now that we support text attributes"
Text attributes are supported now? Is this for ATK as well? If so, I'm not seeing them (Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1a1pre) Gecko/2008071622 Minefield/3.1a1pre). If not, never mind. :-)
Comment 24•16 years ago
|
||
(In reply to comment #23)
> Text attributes are supported now? Is this for ATK as well? If so, I'm not
> seeing them (Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1a1pre)
> Gecko/2008071622 Minefield/3.1a1pre). If not, never mind. :-)
>
Yes, yesterday we have introduced the support of text attributes. They should work in ATK as well. Please try today build.
Comment 25•16 years ago
|
||
By george, you're right! Attributes! Yea!! ;-)
Sorry about that. I suppose I should have built first and then asked. But I figured building FF each and every night, relatively late at night, would have me sufficiently current. Now I know better. :-)
Thanks Alexander!
Updated•16 years ago
|
Assignee: aaronleventhal → nobody
Summary: Text formatting not exposed to screen readers, inaccessible → [meta] Text formatting not exposed to screen readers, inaccessible
Updated•13 years ago
|
Alias: textattra11y
Comment 26•6 years ago
|
||
Keywords: sec508
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•