Re: [g-a-devel]gnopernicus should read new name when received "accessible-name" changed signal

[Bill Haneman <bill haneman sun com>]

Bolian:

I couple of observations and questions.

First, you refer to 'clicking' on days.  Note that blind users will not
in general be using the mouse for this kind of action, what is the
keyboard equivalent and how does that react with gnopernicus?  Also, in
general it's considered correct for objects that react to mouse clicks
to take focus when "clicked on", which from your description doesn't
seem to be the case with the calendat widget.

Calum may have some more questions and observations, so I am cc'ing him
specifically.

thanks

Bill


On Thu, 2003-08-28 at 03:25, Bolian Yin wrote:
> Hi Bill,
> 
> Only report the accessible-name change on focused widget is good.
> 
> My current situation is: in evolution calendar day view model, when you 
> click another day from the calendar on the right, the day view was 
> changed to reflect that change. That means, the title and content of 
> the  day view widget is changed, and day view object is the same. I use 
> the title as the accessible name of the day view widget, and re-set the 
> name to reflect the change of date, expecting gnopernicus to read the 
> new  name. (All the time, the day view widget has the focus).
> 
> As your suggested,  maybe I can make a label to report such a change as 
> "text-change".  But currently the both "label" and the day view are in 
> one "widget", they are all "drawn" by evolution calendar itself.  So I 
> think, if gnopernicus can read "new-name" on receiving the accessible 
> name change signal is better and easier.
> 
> -Bolian
> 
> 
> Bill Haneman wrote:
> 
> >Thanks Bolian.  Your suggestion that property-change:accessible-name
> >should be sent, and listened for, seems correct to me.
> >
> >However, for the actual scenario that led you to log this bug, we
> >probably need to do more thinking.  Under what conditions should such a
> >change be expected, and when should an AT present the new information? 
> >It may be impractical to expect gnopernicus, for instance, to *always*
> >speak accessible-name changes, particularly for widgets that aren't the
> >currently focussed accessible, since a name-change by itself doesn't
> >convey enough context information for a screenreader to make a good
> >presentation.  Is there perhaps another way to present this information
> >which is more 'general', i.e. should the information really be in a
> >ROLE_STATUS_BAR object which is generating text-changes, etc. etc.
> >
> >So I think we should discuss the specific use case here since widgets
> >"changing names" at runtime are not a commonplace occurrence.
> >
> >- Bill
> >
> >
> > Wed, 2003-08-27 at 03:20, Bolian Yin wrote:
> >
> >Bill Haneman wrote:
> >
> >    Your bug report doesn't have any description.  Could you please include
> >    a detailed description and justification?
> >Sorry for that.  I have added description in the bug report:
> >
> >
> >------- Additional Comments From Bolian Yin 2003-08-26 22:12 -------
> >
> >
> >Sorry for the incomplete report.
> >
> >I mean when the accessible-name changed (e.g. by atk_object_set_name),
> >"property-change:accessible-name" signal will be sent out. Gnoperniucs
> >should listen on that and report the new name of the widget.
> >
> >-Bolian
> >
> >
> >
> >
> >
> >
> >
> >_______________________________________________
> >Gnome-accessibility-devel mailing list
> >Gnome-accessibility-devel gnome org
> >http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
> >  
> >
> 
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel