Rob,
To build on what Rich said, the ideal thing is that as best as possible
they way one would label a group is the way it is captured in the ODF
file. This is done in two ways:
1. Make sure the ODF radio/check-box group encoding includes a way to
encode the label [a job of the ODF spec.]
2. Have ODF apps that "do the right thing by default", and ideally
make it more difficult to "get it wrong" -> the user interface for
labeling a group should encode the label properly [a job for the ODF
accessibility guidelines]
To your questions:
As Duane points out, the issue of contradicting group definitions could be
resolved by defining a resolution mechanism. But before we go down that
road, I'd like to see whether this new way of defining radio button groups
in fact adds any expressivity to ODF, or is it merely an equivalent method
of defining groups. I'm not a big fan of adding features twice. It is
hard enough adding them once.
So my questions are:
1) Do we have a problem with radio button accessibility in ODF 1.1?
2) If so, does this proposal address that problem?
3) If not, is this proposal allow implementations to express something
that cannot already be expressed by the existing grouping mechanism?
4) If so, what new does it allow implementations to express?
I'm not certain yet whether we do or don't. More research might be
needed.
When I use OOo 2.4 to create a Button Group, the title/label of the
group box is both visible, and scoping the radio buttons inside it. It
may be redundant with other information (e.g. the form:name
attribute). But it appears the information is there. Need to test
with assistive technologies to see if the ODF apps expose it properly,
but that isn't a format specification issue.
I don't fully understand the proposal, nor what it provides that
doesn't appear to already be present. Perhaps I am missing something?
Regards,
Peter Korn
Accessibility Architect & Principal Engineer,
Sun Microsystems, Inc.
OFF547CBD4.62882F9D-ON8625749C.006F33EA-8625749C.00702A88@us.ibm.com" type="cite">
Rob,
Grouping helps accessibility. Radio buttons are a form of single
selection. By encompassing them in a group you know they are part of
the "select." This is not new to accessibility. In fact there is an
accessibility API role called radiogroup.
Now for the name. If there is a visible name assigned to the group ...
think of it as a label we will need to know that. ODF makes use of
"names" in drawing objects. That is typically a unique name which I did
not want to confuse with the "label" for the radio group.
So, the name or label I am referring to would be "Primitives" below. A
screen reader user would tab to the first focused radio button and say
"Primitives: radio button 4xLine"
Make sense?
Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer
Robert Weir/Cambridge/IBM@Lotus
Robert Weir/Cambridge/IBM@Lotus
08/05/08 01:02 PM
|
|
Backing up a little bit.
This feature proposal came up on Monday's call:
http://wiki.oasis-open.org/office/Grouping_for_Radio_Elements
Since the proposer claimed that it had an accessibility impact:
"Grouping
adds additional structure and helps accessibility" I wanted to evaluate
this specific claim. In particular, I was not aware that we had a
accessibility defect with the way radio buttons are defined in ODF 1.1.
Do we?
The proposer also claims "Currently ODF provides not way to group radio
buttons. The new attribute will add grouping support. "
If grouping means "to associate the radio buttons into a group of
mutually-exclusive controls" then I think we already have grouping
support
in ODF 1.1, via the common name mechanism borrowed from HTML. If the
proposer is intending some other grouping semantics, then this needs
clarification.
As Duane points out, the issue of contradicting group definitions could
be
resolved by defining a resolution mechanism. But before we go down
that
road, I'd like to see whether this new way of defining radio button
groups
in fact adds any expressivity to ODF, or is it merely an equivalent
method
of defining groups. I'm not a big fan of adding features twice. It is
hard enough adding them once.
So my questions are:
1) Do we have a problem with radio button accessibility in ODF 1.1?
2) If so, does this proposal address that problem?
3) If not, is this proposal allow implementations to express something
that cannot already be expressed by the existing grouping mechanism?
4) If so, what new does it allow implementations to express?
-Rob
Malte.Timmermann@Sun.COM wrote on 08/05/2008 01:28:12 PM:
> I also didn't understand the need for group names when the
existing name
> can do the same. The name even doesn't have to be anything
reasonable,
> since it's IMHO internally used only, nothing the user or AT must
> see/read. (A sighted user also won't see it when just using the
form).
>
> If the user should see anything, it's then up to the author to
provide a
> group box or something else, which then can have a name and
description.
>
> Which leads me to the question: Very often you don't have group
boxes
> anymore, but simply a label, maybe with some line.
>
> How can I specify that the label belongs to the group?
>
> Make the XML elements children of that element?
>
> Malte.
>
> Bob Jolliffe wrote, On 05.08.08 18:24:
> > Thinking some more about grouping, I still don't see thast
there is
any
> > need to have a group-name for radio buttons. They are
already
logically
> > grouped by the name. I imagine a screenreader, for example,
would
treat
> > the set in the same way as a select control and read "select
w,x,y or
z"
> > for the named radio buttons.
> >
> > Checkboxes (and other controls) on the other hand may indeed
benefit
> > from grouping in order to render the semantics of "select
all of the
> > following which apply". Perhaps this grouping could be
reasonably
> > achieved through a <form:frame> element which already
does support
> > <form:name>, <form:label> and <form:title>
attributes. As a
> > recommendation one could then specify that all input controls
which
form
> > a coherent group should be contained within a
<form:frame> with a
> > name/label/title which could be exposed to the accessibility
API
> > (regardless of whether this frame is a visible element or
not). This
> > seems to be the closest equivalent of a html frameset.
> >
> > Alternatively these, and perhaps all, elements should have a
> > form:group-name attribute, but I prefer the approach above.
> >
> > Regards
> > Bob
> >
> > 2008/8/5 Richard Schwerdtfeger <schwer@us.ibm.com
> > <mailto:schwer@us.ibm.com>>
> >
> > Rob,
> >
> > We will need to ensure there is a name we can expose to
the
> > accessibility API. Is form:group-name or name="string"
the name of
> > the group that will be rendered? If not we will need to
add
> > <svg:title> somewhere in there for the short name.
> >
> > Rich
> >
> >
> > Rich Schwerdtfeger
> > Distinguished Engineer, SWG Accessibility
Architect/Strategist
> > Chair, IBM Accessibility Architecture Review Board
> > blog: http://www.ibm.com/developerworks/blogs/page/schwer
> > Inactive hide details for Robert
Weir/Cambridge/IBM@LotusRobert
> > Weir/Cambridge/IBM@Lotus
> >
> >
> > *Robert Weir/Cambridge/IBM@Lotus*
> >
> > 08/04/08 10:29 AM
> >
> >
> >
> > To
> >
> > office-accessibility@lists.oasis-open.org
> > <mailto:office-accessibility@lists.oasis-open.org>
> >
> > cc
> >
> > office@lists.oasis-open.org <mailto:office@lists.oasis-open.org>
> >
> > Subject
> >
> > [office] Proposal for Radio Button grouping
> >
> >
> >
> >
> > As you probably know, ODF currently defines the exclusive
selection
> > semantics of radio controls based on radio controls with
the same
name,
> > similar to how this is done in HTML:
> >
> > ODF 1.1, section 11.3.14: "The <form:radio>
element describes
> > controls
> > which act like check boxes except that when several radio
buttons
share
> > the same control name they are mutually exclusive. When
one button
> > is on,
> > all of the other buttons with the same name are off. If
no radio
> > button is
> > initially on, the way in which the application chooses
which
button to
> > turn on initially is undefined."
> >
> > On today's ODF TC call the following ODF 1.2 proposal was
discussed:
> > http://wiki.oasis-open.org/office/Grouping_for_Radio_Elements
> >
> > This proposal would add a form:group-name attribute to
the
form:radio
> > element in section 11.3.14, as an alternative way to
specify
grouped
> > radio
> > buttons. It is not stated how to resolve situations
where both
> > grouping
> > methods are in simultaneous, possibly contradictory use.
> >
> > The Proposer has requested a vote on this proposal for
next
Monday. If
> > the Accessibility SC has any comments, please send them
to the TC
by
> > Friday.
> >
> > Thanks,
> >
> > -Rob
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the
OASIS TC
that
> > generates this mail. Follow this link to all your TCs in
OASIS
at:
> >
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >
>
>
---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC
that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php