Bug 93139 - The orca Screen Reader is silent when placing focus over a bullet in a bulleted list.
Summary: The orca Screen Reader is silent when placing focus over a bullet in a bullet...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: target:5.1.0
Keywords: accessibility
Depends on:
Blocks: a11y-Linux
  Show dependency treegraph
 
Reported: 2015-08-05 13:03 UTC by am_dxer
Modified: 2016-10-25 19:17 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description am_dxer 2015-08-05 13:03:38 UTC
If one creates a bulleted list, presses home to go to the beginning of the line and then presses left arrow to place focus on the bullet, nothing is spoken by Orca. It would be nice to have the screen reader speak bullet and even possibly describe the bullet such as something like "large square bullet."
Comment 1 Joanmarie Diggs 2015-08-11 22:22:26 UTC
Did some quick triage. When you left arrow to the bullet as described in the opening report, the caret moves but there is no accessible object:text-caret-moved event (for that matter, I don't see any other accessible events resulting). Thus Orca has no idea anything happened or that there's something to present.
Comment 2 Joanmarie Diggs 2015-08-14 14:53:57 UTC
In addition, the bullets are not part of the accessible text (which would explain the lack of caret-moved events). To verify:

1. Create a document with a bulleted list.
2. Launch Accerciser.
3. In Accerciser's object tree (on the left), select an accessible list item
4. In Accerciser's iPython console, type the following to get all the text:
   acc.queryText().getText(0,-1)

Expected results: The text returned would include the bullet.

Actual results: The text returned does not include the bullet.
Comment 3 Commit Notification 2015-09-16 08:45:21 UTC
Niklas Johansson committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=64bf04de183a63d32fddf9376307b7f991a4519a

tdf#93139 Orca Screen Reader does not read bullet

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 4 am_dxer 2015-09-17 15:20:05 UTC
Thank you for working on this bug. I can confirm that the bug is partially resolved. If I create documents in the ODT format, bullets are read correctly. However, if I save a file with bullets as a DOC file, close writer, and then open the document in writer again, the bullets are not read.
Comment 5 Niklas Johansson 2015-10-06 20:49:53 UTC
(In reply to am_dxer from comment #4)
>However, if I save a file with bullets as a DOC file, close
> writer, and then open the document in writer again, the bullets are not read.

It seems that when a document is saved in doc file format the bullet characters are replaced with another character, the unicode character 61623 (U+F0B7), that is a bullet character in the Symbol set that Microsoft software usually use. I suppose that the conversion is done to be compatible with Microsoft Office.

Question is what the best way to handle this is. At the moment LibreOffice exposes the character in question but for most fonts it is not a bullet character, so Orca does not interpret it as such. I wonder if the conversion is really needed or just a legacy from the past.
Comment 6 Joanmarie Diggs 2015-10-06 22:12:27 UTC
(In reply to Niklas Johansson from comment #5)
> Question is what the best way to handle this is. At the moment LibreOffice
> exposes the character in question but for most fonts it is not a bullet
> character, so Orca does not interpret it as such. I wonder if the conversion
> is really needed or just a legacy from the past.

It looks like it is not just limited to plain bullets: From a quick test, the checkmark bullet winds up being U+FOFC. I assume this is true of the other bullet types. In addition, the replacement characters appear to be in the Private Use Area. And keep in mind we don't just want to speak the displayed symbol correctly, but also braille the displayed symbol correctly. Long way of saying: I'm extremely hesitant to hack around this in Orca.

If the conversion is really needed -- or if you just don't know for certain -- how hard would it be for you to expose the unconverted (converted-back) symbol via AtkText? Orca won't check to see if you're "lying" to it. ;)
Comment 7 Commit Notification 2015-11-10 12:12:46 UTC
Niklas Johansson committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e2ff5810f1578794aa2617e8d0b44d64642f8eca

tdf#93139 Orca Screen Reader does not read bullet part 2

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Robinson Tryon (qubit) 2015-12-10 03:37:47 UTC
Migrating Whiteboard tags to Keywords: (a11y -> accessibility)
Comment 9 Alex ARNAUD 2016-05-03 09:46:44 UTC
Dear all,
the problem appears with DOC document (cf. comment #4) in version 5.1.2.

Best regards.