Opened 16 years ago
Closed 16 years ago
#3413 closed Bug (fixed)
JAWS does not read Format, Font & Size drop down as combo boxes
Reported by: | Damian | Owned by: | Martin Kou |
---|---|---|---|
Priority: | Normal | Milestone: | CKEditor 3.0 |
Component: | Accessibility | Version: | |
Keywords: | IBM Review+ | Cc: |
Description
JAWS is does not read Format, Font & Size Drop down as Combo Boxes.
For example, in the Paragraph Format combo box, JAWS should read the first option in the combo box followed by "to select the options use arrow keys".
This applies to other combo boxes.
Attachments (1)
Change History (12)
comment:1 Changed 16 years ago by
Owner: | set to Martin Kou |
---|---|
Status: | new → assigned |
comment:2 Changed 16 years ago by
Keywords: | Discusssion added |
---|
comment:3 Changed 16 years ago by
Two problems:
- When a combo box with a selected option is being focused, the selected option gets read instead of the combo box's name. e.g. When I put focus onto the Format combo box, JAWS reads out "Normal" ... which gives a visually impaired user little idea what it actually means.
- When a combo box is opened in Firefox, JAWS is reading out "javascript:void(0)". This is wrong.
comment:4 Changed 16 years ago by
Yes... those are the things that I think should be fixed instead. To make it usable in the way I've described it.
@damo: Do you confirm it's a good solution?
comment:5 Changed 16 years ago by
Yes, I agree that those two points would need to be fixed.
I still need to check whether treating the combo as a command is sufficient. I suppose the question is, will the user know that they have the option to select something from a list after they have activated the command?
Changed 16 years ago by
Attachment: | 3413.patch added |
---|
comment:6 Changed 16 years ago by
Keywords: | Review? added |
---|
comment:7 Changed 16 years ago by
Keywords: | Review- added; Discusssion Review? removed |
---|
I'm testing it with FF3 and JAWS and it looks like the combo entries are not being properly read. It just repeats the combo announcement text for each entry, instead of the entry value. Can you confirm it?
comment:8 Changed 16 years ago by
Keywords: | Review? added; Review- removed |
---|
I don't have the problem here:
http://screencast.com/t/d7bPS0Xu
Some known, but minor, issues:
- When focus is put onto the heading items in format menu, the voice over would seem to repeat the heading style. But that cannot be prevented because we're actually using the Hx tags in the menu and JAWS always reads out Hx tags in addition to the link titles.
- When the style menu is opened the first time, the voice readout would read "Output: Rich text editor, <instance name>, frame" and "Select a style, frame" is any random order. This does seem fixable in any trivial way, but since JAWS would still read out "Select a style, frame" so it's not a big problem.
comment:10 Changed 16 years ago by
Keywords: | Review+ added; Review? removed |
---|
comment:11 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fixed with [3483].
Click here for more info about our SVN system.
I've been thinking about it... and I'm not 100% sure on how we should proceed with it.
I doubt JAWS will understand it as a combo. It's technically a link, and we could try making it understandable as a combo maybe using ARIA, which is not well supported yet.
So, I'm putting myself in the position of a visual impaired person, just hearing the screen reader, with no visual clue that it should be a combo. At that point, I just hear the combos being announced just like any other "command" (note... not button) in the toolbar. So, for the font combo, "Font Style" is read. If I hit ENTER to execute the "command" (not combo), the first option should get read: "Arial" (and this may be a bug, as it's not reading it right now). Hitting TAB, I will just hear that other font style names get read, so I would easily understand that I'm over the options now. Hitting ENTER for the one I want and I'm done (not that a visual impaired person really cares about the font, but just to exemplify).
So, if we don't try to transform what we visualize into expected accessibility behavior, the current system sounds much usable.
Does it makes sense?