|
Bugzilla – Full Text Bug Listing |
| Summary: | ygtk_steps inaccessible ... | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.1 | Reporter: | Michael Meeks <mmeeks> |
| Component: | YaST2 | Assignee: | Forgotten User h13THG8RK1 <forgotten_h13THG8RK1> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | forgotten_h13THG8RK1, mmeeks |
| Version: | Factory | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Michael Meeks
2008-10-06 16:47:54 UTC
So, perhaps the best way to fix this is to use the Gtk Text - that way each paragraph will have it's own a11y peer provided to the system. I guess this: 2006-10-26 Ricardo Cruz <rpmcruz@clix.pt> ... * ygtksteps.c: re-write and made it based on GtkWidget rather than GtkVBox, steps being "hand" drawn by ourselves now, rather than being GtkLabels. This allows for a better integration with YGtkWizard. was a retrograde step a11y wise ;-) but it looks prettier I guess. Are there sizing issues around using GtkTextView [ it seems we can get the indentation & attributes easily enough ]. I was a GTK freshman and implemented a lot of those widgets from the scratch because I thought it was the proper way to go about. However, one problem with simply implementing the thing using the GTK label is that, just like a check button or a radio button, we probably don't want Orca to just read the labels, but to read the statuses as well like "video setup, done", "printer setup, in progress". So, we probably want to implement the painful ATK hooks anyway. The user may also just want the current progress to be read like "current step, printer step, 4 steps to go". Maybe depending where the mouse is pointed at it should read things differently, if that makes sense... Sure - so, turning the outline information into something useful to the impaired is (I guess) the job of a screen-reader yast-specific application skin (of some kind). The first thing to do is to get the information out there I guess. The AT can (at least in theory) extract the 'bold' line from that and present something succinct for people to understand I think. Was my GtkTextView suggestion totally mad ? or is going back to the GtkLabel approach sane :-) Especially as a first step, yeah, let's leave the AT information exporting to GTK. I guess using the GtkTextView would work out fine, and it might simplify things, but it doesn't seem like significatively and the lost of control over the widget could run us into dead ends... For one, the nicer "in progress", "done" reading may be harder to add since we wouldn't have the benefit of the individual step labels... Also, it might be nicer for the Orca user to be able to point to the current step and only having a reading of that particular step... Okay, we now use GtkLabels under a GtkVBox. Current label is set as bold. |