Bill:
You are so clear-sighted. :)
There are keyboard equivalent to the clicking, you can use Left/Right
Arrows to navigate in the day view. These keyboard support only in
recent version of evolution, we just added them weeks ago. Currently,
the calendar widget is NOT focusable, I also think it is a mistake by
design and file a bug for it two days ago, see here:
http://bugzilla.ximian.com/show_bug.cgi?id=47953
Now can you go back to the original questions? Do you think it is
right to rely on accessible-name change in this case?
-Bolian
Bill Haneman wrote:
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
_______________________________________________
Gnome-accessibility-devel mailing list
Gnome-accessibility-devel gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
|
