[g-a-devel]inconsistent in gnopernicus event process for HTML input widgets
From: Simford Dong <Simford Dong Sun com>
To: gnome-accessibility-devel gnome org
Cc: gnome-baum-dev basso sfbay sun com
Subject: [g-a-devel]inconsistent in gnopernicus event process for HTML input widgets
Date: Fri, 24 Jan 2003 14:27:28 +0800
Hi,
I am working on a mozilla bug: #187203(http://bugzilla.mozilla.org/show_bug.cgi?id=187203)
and found some inconsistent actions in gnopernicus for the HTML input widgets:
edit, checkbox, radiobox and combobox. (Attachment #1 is a demo homepage for them.)
For the first three widgets, when first time they got focus, gnopernicus will read the label and status/content.
After that, when the status/content of them changed, gnopernicus reads the status/content only, without label.
For the last widget (combobox), gnopernicus reads the content(list-item) only for both situation!
Attachment #2 is a patch for gnopernicus event process in "gnopernicus/srcore/srmain.c".
Comments are appreciated.
Best regards,
Simford
Title: Examples: WAI Web Content Accessibility Curriculum - slide
"12.4 - Associate labels explicitly with their controls."
Following this checkpoint means that the (non-visual) user will be
able to identify the correct label for a control even if the label is
not located such that it is immediately obvious that it corresponds to a
particular control. Future screen readers or other user agents will be
able to offer this extra information about form controls to the user to
aid their navigation and understanding of complex forms.
The following example lays out four checkbox controls and their text
labels in such a way that the user of a screen reader might have
difficulty determining which label is associated with a particular
checkbox.
It will not hurt your design to start using the LABEL
element now, and your page will be more accessible when agents do start
supporting it. In the meantime, refer to the
example for Checkpoint 10.2 for an accessible fix.