Apache OpenOffice (AOO) Bugzilla – Issue 124363
Writer: Spelling errors not exposed semantically via accessibility APIs
Last modified: 2014-03-11 07:45:39 UTC
Str: 1. Open a new document in Writer. 2. Ensure Writer is set up to do spell checking for English. 3. Type "My tset" (intentional typo, without quotes) and press space. 4. Obtain the accessible for the paragraph just entered. 5. Retrieve the text attributes for offset 3. Expected: There should be an "invalid" attribute with a value of "spelling" ("invalid:spelling"). Actual: There is no "invalid" attribute. You can determine that there is a spelling error because the CharUnderline attribute has a value of 10 (the WAVE underline type). This isn't a major issue because ATs *can* determine that there is a spelling error. However, this is obscure at best. Ideally, this should be exposed semantically, rather than relying on the way it is displayed.
Confirmed. In Symphony, I used UNDERLINE_WAVE (CharUnderline 10) & 0x00FF0000 (CharUnderlineColor) to mark spelling errors. This is not a good way to expose the information to the ATs. I will modify it to use the standard way. Thanks. (In reply to James Teh from comment #0) > Str: > 1. Open a new document in Writer. > 2. Ensure Writer is set up to do spell checking for English. > 3. Type "My tset" (intentional typo, without quotes) and press space. > 4. Obtain the accessible for the paragraph just entered. > 5. Retrieve the text attributes for offset 3. > Expected: There should be an "invalid" attribute with a value of "spelling" > ("invalid:spelling"). > Actual: There is no "invalid" attribute. You can determine that there is a > spelling error because the CharUnderline attribute has a value of 10 (the > WAVE underline type). > > This isn't a major issue because ATs *can* determine that there is a > spelling error. However, this is obscure at best. Ideally, this should be > exposed semantically, rather than relying on the way it is displayed.