Bug 432705

Summary: ygtk_steps inaccessible ...
Product: [openSUSE] openSUSE 11.1 Reporter: Michael Meeks <mmeeks>
Component: YaST2Assignee: 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
The wizard's "steps" widget on the side of each Wizard is not accessible.

We need to either add accessible interfaces (cf. atk.h) and pseudo objects for each of these, or re-work the wizard based on using sub widgets instead (tweaked layout of GtkLabels ?) - to allow the impaired to get access to the step information.

If you use 'accerciser' you can see as you use flat review on yast (num-pad 7/9) with orca enabled, that you can't get into that overview.
Comment 1 Michael Meeks 2008-10-07 09:53:51 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 ].

Comment 2 Forgotten User h13THG8RK1 2008-10-07 13:35:43 UTC
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...
Comment 3 Michael Meeks 2008-10-07 13:46:52 UTC
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 :-)
Comment 4 Forgotten User h13THG8RK1 2008-10-07 14:59:22 UTC
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...
Comment 5 Forgotten User h13THG8RK1 2008-10-08 03:16:10 UTC
Okay, we now use GtkLabels under a GtkVBox. Current label is set as bold.