- From: Janina Sajka <janina@rednote.net>
- Date: Tue, 15 Dec 2009 00:34:25 +0000 (GMT)
- To: Loretta Guarino Reid <lorettaguarino@google.com>
- CC: PFWG Public Comments <public-pfwg-comments@w3.org>
Dear Loretta Guarino Reid:
Thank you for your comments on the 24 February 2009 Last Call Working
Draft of Accessible Rich Internet Applications (WAI-ARIA) 1.0
(http://www.w3.org/TR/2009/WD-wai-aria-20090224/). The Protocols and
Formats Working Group has reviewed all comments received on the draft. We
would like to know whether we have understood your comments correctly and
whether you are satisfied with our resolutions.
Please review our resolutions for the following comments, and reply to us
by 1 February 2010 to say whether you accept them or to discuss additional
concerns you have with our response. You can respond in the following
ways:
* If you have a W3C account, we request that you respond online at
http://www.w3.org/WAI/PF/comments/acknowledge?document_version_id=1;
* Else, by email to public-pfwg-comments@w3.org (be sure to reference our
comment ID so we can track your response). Note that this list is publicly
archived.
Please see below for the text of comments that you submitted and our
resolutions to your comments. Each comment includes a link to the archived
copy of your original comment on
http://lists.w3.org/Archives/Public/public-pfwg-comments/, and may also
include links to the relevant changes in the Accessible Rich Internet
Applications (WAI-ARIA) 1.0 editors' draft at
http://www.w3.org/WAI/PF/aria/20091214/.
Due to the scope of changes made in response to comments on the Last Call
Working Draft of WAI-ARIA, we are returning the specification to Working
Draft status. We will shortly publish a public "stabilization draft" of
WAI-ARIA and updated Working Drafts of the accompanying documents. While
these versions will not incorporate further discussion based on your
acknowledgement of our response to your comments, we will work with you on
your feedback as part of our preparation for the following version. You are
also welcome to submit new comments on the new public versions in addition
to sending your acknowledgement of our response to your previous comments.
Note that if you still strongly disagree with our resolution on an issue,
you have the opportunity to file a formal objection (according to 3.3.2 of
the W3C Process, at
http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews)
to public-pfwg-comments@w3.org. Formal objections will be reviewed during
the candidate recommendation transition meeting with the W3C Director,
unless we can come to agreement with you on a resolution in advance of the
meeting.
Thank you for your time reviewing and sending comments. Though we cannot
always do exactly what each commenter requests, all of the comments are
valuable to the development of Accessible Rich Internet Applications
(WAI-ARIA) 1.0.
Regards,
Janina Sajka, PFWG Chair
Michael Cooper, PFWG Staff Contact
Comment 101: RFC2119
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 <http://www.w3.org/TR/2009/WD-wai-aria-20090224/>
Status: Accepted proposal
-------------
Your comment:
-------------
SHOULD, MUST and MAY need careful review so that it is possible to
determine what qualifies as valid markup and what the expected behaviors
are when requirements marked as SHOULDs are not adopted.
--------------------------------
Response from the Working Group:
--------------------------------
We agree that it is confusing to have normative looking statements in
informative text. We are developing rewording to avoid the confusion and
clarify the intent behind such statements, or converting them into
normative RFC 2119 statements where appropriate. We are also adding the
following clarification: "When the keywords shown above are used, but are
not formatted in bold and uppercase as shown, they do not convey formal
information in the RFC 2119 sense, and should be understood as merely
explanatory, i.e., informative. As much as possible such usages are avoided
in this specification."
----------------------------------------------------------------------
Comment 102: text alternative
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 <http://www.w3.org/TR/2009/WD-wai-aria-20090224/>
Status: Accepted proposal
-------------
Your comment:
-------------
For consistency with WCAG 2.0, consider using "text alternative" instead of
"text equivalent." The rationale is that there are many situations where
alternatives can't be truly equivalent to the original non-text content.
--------------------------------
Response from the Working Group:
--------------------------------
We have made this change.
----------------------------------------------------------------------
Comment 103: Secondary focus
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2.3. Managing Focus <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#managingfocus>
Status: Answered question
-------------
Your comment:
-------------
In some desktop applications, one item may have focus, but another may have
secondary focus. For example, when you use Windows Explorer to browse the
folders on a drive, the name of the current folder has secondary focus
(e.g. gray background colour) while primary focus is somewhere in the files
pane. (Another example of primary and secondary focus can be seen at
http://library.gnome.org/devel/accessibility-devel-guide/nightly/gad-focus-examples.html.en.)
How is secondary focus addressed? Or is this out of scope and should it be
handled by the User Agent (i.e. should secondary focus be considered as
just another managed state)? If secondary focus is covered by the 3rd
paragraph in "2.3. Managing Focus", that isn't very obvious.
--------------------------------
Response from the Working Group:
--------------------------------
While there is not a notion of an operating system having a "secondary
focus" there is the perception that there may be more that one focus point.
Managing this is an authoring practice. Consequently, we have created a
section in the authoring practices guide to address this.
http://www.w3.org/WAI/PF/aria-practices/20091214/#dualfocus
----------------------------------------------------------------------
Comment 104: widget terms
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 <http://www.w3.org/TR/2009/WD-wai-aria-20090224/>
Status: Accepted proposal
-------------
Your comment:
-------------
The distinction between "widgets", "user interface objects" and "user
interface elements" is unclear.
--------------------------------
Response from the Working Group:
--------------------------------
We agree with your comments and your colleague, Charles Chen, had similar
concerns. Consequently, "widgets", "user interface objects" and "user
interface elements" are now simply categorized as "widgets."
----------------------------------------------------------------------
Comment 105: CSS support
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2.2. WAI-ARIA States and Properties <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#introstates>
Status: Alternate action taken
-------------
Your comment:
-------------
Section 2.2. WAI-ARIA States and Properties
The example seems to require that CSS be supported (and turned on) in
order for the role of the list item to be understood visually. Suggest
updating the example to use CSS that is purely presentational instead of
CSS that would change the meaning of the content if not displayed as
intended. Also suggest that the example should be consistent with
subsequent advice in 2.4 to "Use native markup when possible."
--------------------------------
Response from the Working Group:
--------------------------------
This example was intentionally provided to convey how ARIA states and
properties could be used with CSS to trigger visible state information.
This is intended to be a code sample that illustrates a simple point. It is
not meant to be production code. We used aria-checked as we have found this
simple example is easily digested by developers. Consequently, we will
keeping this example.
We agree with you your point that it appears CSS is the only way to render
the visual checked image. We will add some wording to address this.
----------------------------------------------------------------------
Comment 106: Focused element scrolled off screen
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2.3. Managing Focus <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#managingfocus>
Status: Accepted proposal
-------------
Your comment:
-------------
Section 2.3. Managing Focus
The focused element should not be scrolled off screen? What if that is
what the user needs to do, e.g., to consult some distant part of the page
without losing his place.
--------------------------------
Response from the Working Group:
--------------------------------
We agree with your point. Often web applications move focus but obscure it
and our intent was to ensure they did not do that. We did not allow for
user intervention.
We shall change this sentence in the first paragraph of section 2.3
Managing Focus.
<change>
The element with focus should not be destroyed, hidden, or scrolled off
screen.
</change>
<to>The element with focus should not be destroyed or hidden. It should
also not be scrolled offscreen unless through user intervention.
</to>
----------------------------------------------------------------------
Comment 107: All interactive focusable?
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2.3. Managing Focus <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#managingfocus>
Status: Accepted proposal
-------------
Your comment:
-------------
Section 2.3. Managing Focus
When discussing focus management, the statement that all interactive
elements should be focusable seems too strong. A complex widget may contain
elements that never become directly focusable. They may not even become
indirectly focusable if there are other ways to achieve their function,
e.g., keyboard shortcuts.
--------------------------------
Response from the Working Group:
--------------------------------
We understand your concern. We want to be very careful to not run into
another problem, like we did with HTML, where all elements were not
keyboard accessible. Consequently, we want to be careful not to allow a lot
of leeway for the author or host languages to produce an inaccessible
experience. Given that this section is informative we believe the following
modification should address your concern.
<change>
All interactive elements should be focusable
</change>
<to>
All interactive <a href="#def_object">object</a>s should be focusable. All
parts of composite interactive objects (e.g. maximize buttons of grouping
containers) should either be focusable or have a documented alternative
method to achieve their function, e.g., keyboard accelerators.
</to>
----------------------------------------------------------------------
Comment 108: Augment vs override
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2.4. Building Accessible Applications with WAI-ARIA <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#buildingaccessibleapplications>
Status: Accepted proposal
-------------
Your comment:
-------------
2.4. Building Accessible Applications with WAI-ARIA
Roles augment or override the semantics of an element. Will ARIA say when
it augments and when it overrides? Will it be clear what the effect is of
adding a role to different types of elements? Example: tree sample is built
from list elements. Does it matter if it is built from divs, or table
elements? Can I tell from this document whether it matters?
--------------------------------
Response from the Working Group:
--------------------------------
The role attribute will always override implied role of the host language
semantics. The states and properties shall override host language semantics
unless the host language provides a state or property having the same
implied semantics, such as an HTML checkbox.
We have modified the text in this section to address your concern.
----------------------------------------------------------------------
Comment 109: Trees not fully in DOM
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2.4. Building Accessible Applications with WAI-ARIA <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#buildingaccessibleapplications>
Status: Accepted proposal
-------------
Your comment:
-------------
2.4. Building Accessible Applications with WAI-ARIA
Advice about trees that are not completely represented in the DOM seems a
little odd. AT will need to support two different ways of expressing the
same relationships. And it still seems possible that you will need
ARIA-OWNS, depending on how the tree is implemented structurally.
--------------------------------
Response from the Working Group:
--------------------------------
Per our discussion we agreed this comment actually applied to section 2.5
Building a Tree Widget. We agree this information could be made clearer and
will make the appropriate changes.
----------------------------------------------------------------------
Comment 110: Expand example
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2.5. Example: Building a Tree Widget <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#Exampletree>
Status: Alternate action taken
-------------
Your comment:
-------------
Section 2.5. Example: Building a Tree Widget
Comment 10: Step 4 needs more implementation detail - it is meant to be an
example.
--------------------------------
Response from the Working Group:
--------------------------------
The working group intentionally did not extend the code example to this
section. The group felt that in order to provide script examples it would
unnecessarily increase the size of the specification and detract from what
the specification would convey. For example, the script used to implement
keyboard and mouse support would also vary between each browser
dramatically increasing the specification size.
The group does agree the reader is left hanging and that we shall point
the user to an implementation of the design pattern in the best practices
guide.
----------------------------------------------------------------------
Comment 111: Columns expandable
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2.5. Example: Building a Tree Widget <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#Exampletree>
Status: Answered question
-------------
Your comment:
-------------
Section 2.5. Example: Building a Tree Widget
It seems that only rows are expandable in a grid. Is there a reason that
columns should not also be expandable?
--------------------------------
Response from the Working Group:
--------------------------------
At this point, the only requirements for aria-expanded in a grid has been
for rows and gridcells. If we were to have both row and column expansion
capability, it would require a new set of WAI-ARIA properties to indicate
that for a given cell you could expand the row and the column. This would
also require an expansion in accessibility API support as well as a deeper
look into key bindings.
If your requirement is to just add a column to your grid, it is possible
to have an aria-haspopup on any element, such as a columnheader, where the
user could choose to expose a popup menu containing a menuitem to insert a
new column.
Due to the complexity of having bidirectional column expansion, from the
perspective of users and accessibility APIs, we have decided to create this
as an issue for the ARIA 2.0 time frame.
----------------------------------------------------------------------
Comment 112: Text equivalent note
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.7.3. Text Equivalent Computation <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#textequivalentcomputation>
Status: Accepted proposal
-------------
Your comment:
-------------
4.2.7.3 Text Equivalent Computation
The note at the end of the text equivalent computation is somewhat
confusing and it's not clear whether it applies only to item 3 in the
preceding list or to all items in the list. Please clarify what is meant
here so that it can not be interpreted to mean that calculated text
equivalents should not have structure.
--------------------------------
Response from the Working Group:
--------------------------------
The note at the end of the text equivalent computation applies to all
items, not just item 3.
The text equivalent computation outlined in the UA implementation guide
[1] is clearer. There, steps 3 and 4 indicate that whitespace is handled
at the end of the previous step 2, where whitespace is trimmed and/or added
as text is assembled in the previous step.
We will change the note to clarify:
<change>
Note: The purpose of the flat text equivalent string is to create
something readable in alternative presentations. An implementation should
insert whitespace characters when visually separate elements would be
"jammed" together in the same string. For example, a space character may be
inserted between the text of two paragraphs used one after the other in a
description.
</change>
<to>
Note: The purpose of the flat text equivalent string is to create
something readable in alternative presentations. At each step of the
algorithm, an implementation should trim the existing text equivalent
string and the string to be added, then join those two strings with a
single space. For example, a space character may be inserted between the
text of two paragraphs used one after the other in a description.
</to>
[1]
http://www.w3.org/WAI/PF/aria-implementation/20091214/#mapping_special_te
----------------------------------------------------------------------
Comment 113: Text equivalent / text nodes
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.7.3. Text Equivalent Computation <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#textequivalentcomputation>
Status: Answered question
-------------
Your comment:
-------------
4.2.7.3 Text Equivalent Computation
Is this consistent with how text nodes are built in HTML, both in practice
in current browsers and also under HTML 5? Perhaps this should be covered
in the Implementors Guide or API mapping tables?
--------------------------------
Response from the Working Group:
--------------------------------
In general, the use of @role and @aria-* do not affect how user agents
construct the DOM. The aria attributes are informative and affect the DOM
only to the extent that they are added to the set of content attributes of
the elements they are associated with.
Specifically, aria attributes, such as aria-label and aria-labelledby, and
the text equivalent computation do not affect how user agents build text
nodes. The purpose of the text equivalent computation is to generate a
flat string to publish via the accssibility API for use by an assistive
technology. The assistive technology can then present the text as needed;
for example, a screen reader can speak it.
----------------------------------------------------------------------
Comment 114: AccValue instead of AccName
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.7.3. Text Equivalent Computation <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#textequivalentcomputation>
Status: Alternate action taken
-------------
Your comment:
-------------
4.2.7.3 Text Equivalent Computation
Additional contribution of user-entered data. Shouldn't this be the
AccValue rather than the AccName?
--------------------------------
Response from the Working Group:
--------------------------------
Step 2B of the text equivalent calculation addresses a situation where the
AccValue of a control participates in the construction of a larger label.
This is a specific case where an author has embedded a control within a
label. For example, consider a checkbox whose label contains a text input
field:
[X] Flash the screen [input] times.
If the user has entered "5" for the input, the complete label for the
checkbox is "Flash the screen 5 times".
Computing the label for the checkbox involves retrieving the "value" of
the embedded control, although what is retrieved from the embedded control
depends on its type. If the embedded control is a, say, <select> element,
then the "value" is the currently selected <option>.
Note that rule 2B is being reworded based on other comments, and will be
more explicit in terms of how an embedded control contributes to a larger
label.
----------------------------------------------------------------------
Comment 115: Rendered text
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.7.3. Text Equivalent Computation <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#textequivalentcomputation>
Status: Alternate action taken
-------------
Your comment:
-------------
4.2.7.3 Text Equivalent Computation
Is it really a good idea to use rendered text instead of the DOM? This
creates yet another interpretation of the html, and seems like it could
lead to subtle bugs.
--------------------------------
Response from the Working Group:
--------------------------------
Consider these style rules and fragment of HTML markup:
p[title]:before { content: attr(title); }
<p title="Step 1:">Put up the tent.</p>
A user agent (browser) will render this as:
...
Step 1: Put up the tent.
...
Because the title attribute is only included if there is no other text
content, the DOM representation of the text equivalent is "Put up the
tent."
Though a user agent should make its best effort to compute a text
equivalent from CSS-generated text in the absence of text content
determinable from the DOM, authors should not provide text through a style
sheet, as a user agent may incorrectly determine the text equivalent.
Authors need to be aware how the label text will be computed by the user
agent, so as to structure markup and CSS appropriately. Since they are
creating the CSS content rules, they must have an idea of how the entire
string will look.
In the case of a text equivalent checker tool that authors might use to
confirm that their labels are properly encoded: the checker tool must,
like user agents, look for any CSS content and insert/append it as
necessary.
----------------------------------------------------------------------
Comment 116: Text equivalent examples
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.7.3. Text Equivalent Computation <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#textequivalentcomputation>
Status: Accepted proposal
-------------
Your comment:
-------------
Some examples of markup and the resulting AccName would be really useful
here.
--------------------------------
Response from the Working Group:
--------------------------------
We have added examples at the end of the text alternative computation
section.
http://www.w3.org/WAI/PF/aria/20091214/roles#tac_example1
http://www.w3.org/WAI/PF/aria/20091214/roles#tac_example2
----------------------------------------------------------------------
Comment 117: Why roles abstract
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.3. Categorization of Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#roles_categorization>
Status: Answered question
-------------
Your comment:
-------------
section 4.3.1 contains a note that authors should not use abstract roles in
content. The lists in 4.3.2 (user input widgets) and 4.3.4 (document
structure)
contain a few roles that are marked as abstract but that would be useful
in content, especially section and sectionhead. Why are these abstract?
--------------------------------
Response from the Working Group:
--------------------------------
Like any class hierarchy there are generic abstract classes which are used
to describe concepts in the hierarchy. Specifically, section was deemed
abstract as we have numerous more explicit classifications of "sections" in
the WAI-ARIA taxonomy as can be seen at
http://www.w3.org/WAI/PF/aria/20091214/rdf_model.png. Furthermore, a <div>
in HTML is converted to a platform specific role of "section" in platform
accessibility APIs. For generic perceivable sections we have the role of
region which may be used for this purpose and which explains how it should
be used.
Also, we want to make it clear that ARIA roles are based on a semantic
model. As for sectionhead we have numerous types or roles which are
considered a sectionhead in nature. Please refer to the taxonomy link
provided in the first paragraph. If the author is to use a generic section
head we decided to be consistent with HTML and use the role of heading and
to include the option of providing an aria-level. The author may also use
the standard header tags over the heading roles. Per the Best Practices
Guide we request authors to use the aria-labelledby property to explicitly
assign the heading to the section it is labelling. Like the use of
aria-describedby this allows for consistency throughout the specification.
We also feel by using headings to label sections of the document we can
also be consistent with WCAG best practices for providing header
navigation.
We are adding this explanation to the specification to help ensure it is
clear to readers.
----------------------------------------------------------------------
Comment 118: Table of roles, states, properties
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.3. Categorization of Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#roles_categorization>
Status: Accepted proposal
-------------
Your comment:
-------------
We would like to see (possibly as an appendix) a table that lists all
concrete roles and all properties and states supported by each role.
--------------------------------
Response from the Working Group:
--------------------------------
We agree to add an appendix that has a quick reference for all concrete
roles that shows the supported states and properties of each. This is an
excellent suggestion.
----------------------------------------------------------------------
Comment 119: Abstract vs base
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.3. Categorization of Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#roles_categorization>
Status: Alternate action taken
-------------
Your comment:
-------------
What is the difference between and abstract and a base role. What do base
roles add?
--------------------------------
Response from the Working Group:
--------------------------------
We agree with your point about separating input widgets and user interface
elements is confusing and requires simplification. We also agree with
another comment that separating out abstract roles and base types is a bit
confusing and that adding a base type (a categorization of some abstract
classes) creates more confusion.
What we do feel is important is to ensure there is an understanding of
which widgets convey structure. Regarding the application role, the group
resolved, a while back, to have the application role be included in the
list of landmarks.
This is also reflected in the WAI-ARIA Best Practices Guide.
So we will be adopting a hybrid of your proposal, as shown at
http://www.w3.org/WAI/PF/aria/20091214/roles#roles_categorization.
----------------------------------------------------------------------
Comment 120: Meaning of
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.3. Categorization of Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#roles_categorization>
Status: Answered question
-------------
Your comment:
-------------
HTML 5 uses "dialog" to mean something entirely different than ARIA (In
HTML 5, a dialog between two speakers, as in a dramatic script).
--------------------------------
Response from the Working Group:
--------------------------------
WAI-ARIA is designed to support interoperability through platform
accessibility APIs. The role of dialog has been a standard role in platform
accessibility API since 1995 when MSAA was first introduced. It is also
used in Java, IAccessible2, and Linux ATK/ATSPI. Furthermore, we have
considerable implementation already in the major browsers for the WAI-ARIA
role of dialog.
HTML 5 is not at recommendation stage and could change at any time and
therefore the HTML working group could do away with their use of dialog or
rename it in the future. For these reasons, the consistency with platform
accessibility API, and the enormous implementation support we already have
for dialog we believe that the current HTML 5 naming for dialog (used for
the purpose of a conversation) should change during WAI-ARIA integration
with HTML 5 down the road. We have made this clear in discussions with the
HTML working group. Consequently, we will not be changing our use of the
role dialog but will work with the HTML working group on an alternative
name for there use of dialog going forward as we move to integrate WAI-ARIA
with HTML 5.
----------------------------------------------------------------------
Comment 121: Application landmark or structure
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.3.6. Landmark Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#roleattribute_inherits>
Status: Alternate action taken
-------------
Your comment:
-------------
Why is application a landmark role instead of an application structure
role? Its use for navigation seems much less important than its use in
changing the interaction model for that region.
--------------------------------
Response from the Working Group:
--------------------------------
The group had a lot of deliberation on this and decided to place
role="application" in to the landmark for these reasons:
- Members wanted to be able to jump to a particular application on the
page (remember these will have labels). To do this, the simplest interface
for screen readers was to bring this up into the landmarks navigation
dialog. This is now in a major screen reader vendor's beta. Authors need to
be able to identify applications as part of their general layout. If we
treated it like a special region it would not then be included in the list
of landmarks.
- When changes were made to screen readers to support WAI-ARIA widgets
they found that by switching into application mode automatically when
landing on the widget removed the need for switching the interaction model
on an application region basis. So, the only time application role changes
the interaction mode is when placed on the body tag. So, treating it as a
landmark when used within the body tag (as a regional landmark) is going to
operate like all other regions.
What we want authors to do is mark application sections as landmarks and
label them. This is the same procedure they will follow for landmarks.
Should they want to place a role of application on the body tag then the
specification defines the interaction model.
We have added a note to the application role to clarify how it is a
landmark and the circumstance in which it is not:
In the spec, add the following text to the description of the landmark
role:
Authors MAY use the application role on the main content element of the
host language (such as the body element in HTML) to define entire page as
an application. However, if the main content element is defined as having a
role of application, user agents MUST NOT use the element as a navigational
landmark. If assistive technology uses an interaction mode that intercepts
standard keyboard events, when encountering the application role, assistive
technology SHOULD switch to an interaction mode that passes keyboard events
through to the web application.
In the UAIG for HTML and SVG, add the following:
If the role attribute is missing from the main content element, user
agents MUST treat the element as having the default role of document.
----------------------------------------------------------------------
Comment 122: Breadcrumbs role
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.4. Definition of Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#roles>
Status: Alternate action taken
-------------
Your comment:
-------------
We suggest that PF consider making breadcrumbs a role. This is a very
common feature on websites and it confuses blind users (e.g. user follows
links to product description and then encounters breadcrumb trail that
starts with "You are here: Home > ...", but "Home" is not the destination
he/she had in mind). Of course, this role does not map to an existing
accessibility API (at least not in Gnome/ATK, javax.accessibility,
IAccessible2, Apple)
There would only be one role for the entire Breadcrumb trail, with no
special states or properties. It might look something like this.
<pre>
<p role="breadcrumbs">
You are here:
<a href="../../index.htm">Home></a><a href="../books.htm">Books></a><a
href="winnie.htm">Winnie the Pooh</a></p>
</pre>
Would look like this.
You are here: Home>Books>Winnie the Pooh
* Parent Roles:none (perhaps menu, navigation, landmark??)
* Child Roles: none
* Related Concepts: menu, list, tree, navigation, landmark
* Inherited States and Properties: None
* Global States and Properties; None
--------------------------------
Response from the Working Group:
--------------------------------
The group initially had a breadcrumbs role. There was consensus that a
navigation role could be used instead to simplify the number of landmarks
the author and AT had to be concerned about.
It is true that a breadcrumbs role would need to be added to some
accessibility API. However, an even bigger hit would be to have ATs add
support for another landmark. Also, a screen reader vendor, in order to
treat this differently, would need to do additional scripting to convey
meaning about the breadcrumbs trail. Unfortunately, we don't have runway to
get that in an AT in time for last call.
Given that we have a generic solution in place with role="navigation" we
will defer the role="breadcrumbs" landmark use case for ARIA 2.0. This will
allow us more time to get AT vendors, API, and browsers on board should the
group agree to the new role. We have created an issue for ARIA 2.0 to
address this.
----------------------------------------------------------------------
Comment 123: Menu not in menubar
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.4. Definition of Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#roles>
Status: Accepted proposal
-------------
Your comment:
-------------
What is the appropriate role for a control that opens a menu, but is not in
a menubar? If it were in a menubar, it appears to be 'menuitem'. But can
'menuitem' exist outside of a menubar or menu? If not, why would the same
control have a different role inside a menubar and outside a menubar?
Please clarify in the spec.
--------------------------------
Response from the Working Group:
--------------------------------
In order for a control to indicate that it opens a menu you simply need to
set its aria-haspopup property to "true." aria-haspopup is a global
property so that it can be applied to anything. The keyboard style guide
indicates the type of menu being launched (submenu, context help, etc.).
Specifically, in the case of menus, menubars, and menuitems you simply set
the aria-haspopup property ="true" on menuitems to indicate they support a
popup menu. menu and menubar are simply containers for types menu items as
articulated in the text.
We have clarified text in menuitem to convey how the author should use
aria-haspopup to convey that the menuitem supports a submenu.
We shall add text to the ARIA BPG to indicate how any component can
support a popup menu through the use of aria-haspopup.
----------------------------------------------------------------------
Comment 124: Splitbutton
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.4. Definition of Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#roles>
Status: Proposal not accepted
-------------
Your comment:
-------------
We suggest considering a splitbutton role.
--------------------------------
Response from the Working Group:
--------------------------------
WAI-ARIA does allow for a button to have a dropdown. By setting the
aria-haspopup property on a button, an AT will know a menu of choices can
be launched. Then it is just a matter of rendering a WAI-ARIA enabled menu.
Consequently, you should have what you need in WAI-ARIA 1.0 to support
splitbutton functionality with AT support, therefore we will not be
creating a new splitbutton role at this time. If you feel you need more
functionality please submit it as a WAI-ARIA 2.0 issue so that we may
address it. Per our discussions you had with Rich this was acceptable.
----------------------------------------------------------------------
Comment 125: Alert dialog focusable?
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - alertdialog (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#alertdialog>
Status: Answered question
-------------
Your comment:
-------------
alertdialog (role), dialog (role)
"When the alert dialog is displayed, authors SHOULD set focus to an active
element within the alert dialog." Is setting focus to the alert dialog
itself an option? This can permit AT to read the entire dialog
automatically, which can be less confusing than setting focus to an
interactive element, perhaps skipping over the alert message itself.
Nesting focusable items can cause some confusion in browsers, however,
particular for rtl languages. Either User Agent Implementation or Best
Practices discusses expected behavior of the screen reader, so the answer
may be implicit in that discussion.
--------------------------------
Response from the Working Group:
--------------------------------
Operating systems do not set focus to the dialog frame, so setting the
focus to the alert dialog itself would be inconsistent with operating
system dialogs. Also, assistive technologies are accustomed to announcing
dialog features, like the dialog message, which would not automatically be
spoken if focus were placed on the dialog box itself. Placing keyboard
focus on the dialog frame may help users who are blind but sighted users
who are accustomed to having keyboard input applied to actual interactive
widgets would be frustrated. In short, this would not be consistent with
desktop usage.
The ARIA Best Practices Guide describes how to implement accessible
dialogs and in fact indicates that a describedby relationship be applied to
the ARIA dialog role to reference a message to be spoken should one exist
when the dialog first becomes active. This is supported in the latest JAWS
build.
Regarding the use of SHOULD, the working group has decided that SHOULD and
not MUST be used in the WAI-ARIA specification as we cannot mandate
authoring techniques. We do however indicate an RFC 2119 SHOULD which is a
very strong recommendation that they set focus on a focusable element in
the dialog.
----------------------------------------------------------------------
Comment 126: Unclear meaning
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - article (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#article>
Status: Accepted proposal
-------------
Your comment:
-------------
alertdialog (role), dialog (role)
The syntax in the sentence "Assistive technology must treat an article
like a document in that article must be processed like an application."
looks disjointed. The intent is not clear. This may be an editorial issue,
but since the intent is not clear, we can't suggest an alternative wording.
--------------------------------
Response from the Working Group:
--------------------------------
We agree this is unclear. We are making the following change:
<change>
Assistive technology must treat an article like a document in that article
must be processed like an application. Unlike a document, the use of
articles allows the user to identify and follow related articles based on
the nesting.
</change>
<to>
When a user navigates an element assigned the role of article, assistive
technology that typically intercepts standards keyboard events MUST switch
to document browsing mode, as opposed to passing keyboard events through to
the web application. Assistive technologies MAY provide a feature allowing
the user to navigate the hierarchy of any nested articles.
</to>
----------------------------------------------------------------------
Comment 127: Name of banner role
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - banner (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#banner>
Status: Proposal not accepted
-------------
Your comment:
-------------
People may think this is a banner ad, not the main title of the page.
Perhaps "nameplate" would be a term that better reflects this concept
("masthead" and "flag" are other common terms from the desktop publishing
world for this).
--------------------------------
Response from the Working Group:
--------------------------------
We understand your concern. Banner does have its roots in banner ads yet
over the years it has evolved into what we consider our current definition
in the ontology. Although banners can consist of ads they are not only ads.
In fact, they provide information about the actual site: We offer some
examples:
- http://isp.webopedia.com/TERM/B/banner.html
- http://obiee101.blogspot.com/2009/06/obiee-new-portal-banner.html
Our definition of the banner role is based on the definition in the XHTML
Role Attribute module which in turn was derived from its use in Portlets.
Its definition is also consistent with this text:
http://books.google.com/books?id=ora_cfGNRWkC&pg=PA320&lpg=PA320&dq=elements+of+a+portal+banner&source=bl&ots=zhjLBAPNXM&sig=1MHpuX9vP08lKU7__uoUPlm6Y3E&hl=en&ei=i0FSSpzCNJyqtgfCw62zBA&sa=X&oi=book_result&ct=result&resnum=3
Finally, authors are familiar with using "banner" vs. "nameplate" or
"masthead." Here is an example of a reference to "banner" albeit the actual
definition is omitted:
-
http://download.oracle.com/docs/cd/E12839_01/portal.1111/e10235/glossary.htm#CHDDCAJG
- http://docs.sun.com/source/816-6758-10/ch6.html
For these reasons we feel our definition of banner is consistent with what
developers are using and the latest text definition of banner.
Introducing a new term to developers is something we would like to avoid.
Consequently, we shall continue to use the banner role as defined.
----------------------------------------------------------------------
Comment 128: Heading in banner
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - banner (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#banner>
Status: Accepted proposal
-------------
Your comment:
-------------
The use of 'primary heading' and 'main heading' in the banner role is
somewhat confusing. In general, we would have expected that the h1 for a
given page would more commonly reside in the "main" landmark role. Suggest
revising the definition of the banner role to focus only on site-oriented
content (ex. CNN Technology or Yahoo Finance).
--------------------------------
Response from the Working Group:
--------------------------------
We have made the following changes in the ARIA document:
Change the definition under "banner (role)" to:
"A region that contains the primary identification of a site."
Change:
"Site-oriented content typically includes things such as the logo of the
site sponsor, the main heading for the page, and site-specific search
tool."
to:
"Site-oriented content typically includes things such as the logo or
identity of the site sponsor, and site-specific search tool."
----------------------------------------------------------------------
Comment 129: Tri-state checkbox in HTML
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - checkbox (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#checkbox>
Status: Accepted proposal
-------------
Your comment:
-------------
We recommend working with HTML5 to incorporate tri-state checkboxes.
--------------------------------
Response from the Working Group:
--------------------------------
An issue has been raised for the WAI-PF HTML review task force to take this
requirement to the HTML working group.
----------------------------------------------------------------------
Comment 130: Sortable headers
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - columnheader (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#columnheader>
Status: Answered question
-------------
Your comment:
-------------
columnheader (role), rowheader (role)
Should there be a role for column and row headers that support sorting
when clicked? (gridcolumnhdeader/gridrowheader?)
--------------------------------
Response from the Working Group:
--------------------------------
No, this would be mixing the role, or type, semantics with the action to be
performed.
Depending on the accessibility API used, user agents may implement an API
based on analyzing the aria-sort property along with the columnheader
(role) or rowheader (role) to provide an action with a description of "sort
ascending" or "sort descending." Alternatively, a default action could be
provided for older accessibility APIs. Both allow the assistive
technologies to activate the object in a device-independent way.
----------------------------------------------------------------------
Comment 131: Clarify combobox
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - combobox (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#combobox>
Status: Accepted proposal
-------------
Your comment:
-------------
"Many browsers allow users to type in a drop-down select as well." This
statement gives the impression that a standard <select> element in HTML
allows free text input. Typing in an HTML drop-down list selects an option
that start with the character you type but does not generate new strings
(in Internet Explorer, Firefox, Opera and SeaMonkey on Windows XP). This
statement needs to be seriously qualified.
--------------------------------
Response from the Working Group:
--------------------------------
We have chosen to clarify the statement you called out from the ARIA
specification. We believe our meaning is conveyed in the statement "The
combobox may be editable".
----------------------------------------------------------------------
Comment 132: complementary vs article
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - complementary (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#complementary>
Status: Accepted proposal
-------------
Your comment:
-------------
complementary vs article
How do these two roles differ? From the descriptions, we can't tell when
it is appropriate to use one or the other.
--------------------------------
Response from the Working Group:
--------------------------------
We agree these could be made clearer. In particular, complementary sections
are navigational landmarks where an article is not. The role complementary
is also secondary to the main content, even though it should be able to
stand on its own.
An article is a document section that is not a landmark. It is, however, a
document which can be nested to form a discussion thread. The nesting is
important to supply context to the user.
We shall be making editorial changes to article and ARIA navigational
landmarks to clarify their definitions.
----------------------------------------------------------------------
Comment 133: Unclear contentinfo
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - contentinfo (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#contentinfo>
Status: Accepted proposal
-------------
Your comment:
-------------
We have trouble determining when this is the appropriate role, examples
notwithstanding. Is the author's name metadata? Why is a footnote metadata?
It breaks the linear order, but otherwise seems to be content of the
document, not metadata about the document. Are references metadata?
--------------------------------
Response from the Working Group:
--------------------------------
We agree that the way this is is written it does not reflect the purpose of
the role.
contentinfo is a large perceivable region, treated as a navigational
landmark by assistive technologies, that contains information about the
parent document.
Examples of information included in this region of the page would be
copyrights and links to privacy statements.
We are adding a request that authors provide no more than one element with
the contentinfo role to discourage authors from overusing the contentinfo
role and also to provide restrictions in the mapping of the contentinfo
role to host language elements.
----------------------------------------------------------------------
Comment 134: Heading levels
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - heading (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#heading>
Status: Answered question
-------------
Your comment:
-------------
Consider adding support for heading levels.
--------------------------------
Response from the Working Group:
--------------------------------
We have support for aria-level in heading:
http://www.w3.org/TR/wai-aria/#heading
----------------------------------------------------------------------
Comment 135: link behavior
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - link (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#link>
Status: Alternate action taken
-------------
Your comment:
-------------
The description does not say how this relates to the XLink behaviour
attributes (http://www.w3.org/TR/xlink/#link-behaviors). Can the link role
only be used for links that load the referenced resource in the same way as
traditional HTML hyperlinks (fetch and display instead of the current
content, or fetch and display in a new window) or can link traversal also
result in embedding? If this role is not intended for embedding on request,
what other role would be appropriate?
--------------------------------
Response from the Working Group:
--------------------------------
Rich spoke with Christophe Strobbe on this. The link behavior is equivalent
to basic link behavior found in HTML 4. We will clarify this in the
specification. HTML 4.X does not provide the full xlink behavior so adding
xlink functionality would be a change to the user experience. That said,
HTML 5 provides for a richer link behavior comparable to xlink. To address
the full behavior functionality of XLink will require platform
accessibility API modifications as well as changes to ARIA which is beyond
the scope of ARIA 1.0. We have created an issue for ARIA 2.0 to consider
adding full xlink behavior.
----------------------------------------------------------------------
Comment 136: Mixed menuitemcheckbox and menuitemradio
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - menuitemradio (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#menuitemradio>
Status: Alternate action taken
-------------
Your comment:
-------------
What is the behavior if a menu contains both menuitemcheckboxes and
menuradioitems? is this allowed (current wording seems to allow it). Does
this permit only one radio button to be selected, but arbitrarily many
checkboxes to be checked, too? If a menu wants to contain 2 different sets
of radio items, is there a way to group them so that one may be selected
from each set? Is this one of the potential uses of group as a child of
menu? That is, does the use of "group" in the second paragraph refer to the
role group? Typography doesn't seem to indicate this. And the third
paragraph seems to indicate that menuradioitem should be a child of menu.
Should role radiogroup be used for this purpose in this context? How does
the reference to type separator fit into definitions of discrete groups?
Are all items between separators considered part of the same group? (note
that this is spelled out explicitly for treeitems - a good model?.)
--------------------------------
Response from the Working Group:
--------------------------------
we've added the previous text to menuitemradio
----------------------------------------------------------------------
Comment 137: Option in menu
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - option (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#option>
Status: Accepted proposal
-------------
Your comment:
-------------
The description of option indicates it can be associated with a menu, but
the description of menu makes no mention of option. How is option different
from menuitem?
--------------------------------
Response from the Working Group:
--------------------------------
Yes, this is an error. It is being corrected.
----------------------------------------------------------------------
Comment 138: Clarify presentation
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - presentation (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#presentation>
Status: Accepted proposal
-------------
Your comment:
-------------
The definition says "An element whose role is presentational and does not
need to be mapped to the accessibility API."
Should a layout table be marked up as a table element with role
'presentation'? Will the content of such a table still be exposed to AT?
that is, does the definition mean that the element isn't exposed to AT, or
the role isn't mapped to the accessibility API? The longer description of
role presentation makes it clearer that the role is not exposed, but the
content is (or may be?) exposed. Is the decision about whether content is
exposed a function of the element type that has role presentation? If so,
can the spec document the expected behavior?
Current discussion on the free-aria list seems to indicate that browsers
(at least Firefox) are not interpreting role=presentation this way; they
appear to remove all trace of the presentation nodes from being exposed to
AT via the API.
The second example in the description of role presentation is confusing.
What is the user agent's default behavior for a list item that is being
overridden by assigning role=presentation to the li element? Is it the
styling as list elements that is overridden? Is it the inclusion of the
element in the list's set of items?
--------------------------------
Response from the Working Group:
--------------------------------
We have made extensive edits to the role definition to clarify presentation
inheritance and added a rowgroup role as per comment 290. See
http://www.w3.org/WAI/PF/aria/20091214/roles#presentation.
----------------------------------------------------------------------
Comment 139: Search role instead of property
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - search (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#search>
Status: Accepted proposal
-------------
Your comment:
-------------
Why is this a separate role, and not just a text input with accName=Search?
--------------------------------
Response from the Working Group:
--------------------------------
The reason we have a search role is to define a regional landmark in the
page which may contain a text field, a set of checkboxes, and so on. For
example, you might have a checkbox which says case-sensitive. In short, the
search region of your page may constitute a number of widgets that control
the search that collectively form the search region. Consequently, search
is a role and a navigational landmark.
We shall make this more clear in our specification.
----------------------------------------------------------------------
Comment 140: Clarify tab and tabpanel
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - tabpanel (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#tabpanel>
Status: Accepted proposal
-------------
Your comment:
-------------
tab (role), tabpanel (role)
What's the relationship between a tab and its tabpanel? How is it made
explicit? A markup example would be really useful here.
--------------------------------
Response from the Working Group:
--------------------------------
We agree with your comment and consequently providing additional
information in tab, tablist, and tabpanel to convey their association.
----------------------------------------------------------------------
Comment 141: tooltip behavior
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - tooltip (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#tooltip>
Status: Alternate action taken
-------------
Your comment:
-------------
"A contextual popup that displays a description for an element in a mouse
hover or keyboard focused state. Supplement to the normal tooltip
processing of the user agent. "
We need a way to activate tooltips from the keyboard, but we think it is a
serious mistake to bring them up on focus. The parallel would be if
tooltips came up on blur (that is, as soon as the mouse entered that
region.) Users need to hover over a control to get a tooltip because there
are too many times when that is not the desired behavior and it would be
very distracting. Similarly, if a user needs to tab through a series of
controls to reach the one she needs, having tooltips pop up on each control
as she tabs through will be very distracting, at best, and will likely slow
down her ability to reach the desired control. Having it appear
automatically may be okay in some cases (ex. additional info on a form
input) but for things like links, there ought to be a way for users to ask
for it to appear instead of having it appear automatically. We suggest
changing "keyboard focused state" to "keyboard activated state".
--------------------------------
Response from the Working Group:
--------------------------------
We have modified the specification to state:
A contextual popup that displays a description for an element.
The tooltip typically becomes visible in response to a mouse hover, or
after the owning element receives keyboard focus (typically with a delay).
----------------------------------------------------------------------
Comment 142: Map properties to CSS
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.6. Definitions of States and Properties (all aria-* attributes) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#state_prop_def>
Status: Alternate action taken
-------------
Your comment:
-------------
We'd like to see a mapping from ARIA states and properties to CSS
pseudoclasses. Many of these things can be set in multiple ways (aria
attributes, html attributes, user actions), and it would be nice for CSS
designers to not have to know about those details.
--------------------------------
Response from the Working Group:
--------------------------------
The definition of CSS pseudo-classes is managed by the CSS working group.
We shall address the addition of new WAI-ARIA pseudo-classes with the CSS
working group. The ARIA specification itself, however, is the appropriate
place to define CSS pseudo-classes.
----------------------------------------------------------------------
Comment 143: Controls vs owns
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-controls (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-controls>
Status: Answered question
-------------
Your comment:
-------------
What's the difference between aria-controls and aria-owns? How would an
author decide which to use? Markup examples would be useful here.
--------------------------------
Response from the Working Group:
--------------------------------
aria-owns and aria-controls are entirely different properties.
aria-controls is used when an object is controlling an entirely separate
object. For example, it is not used to establish controls relationship
between a grid and its gridcells. "X aria-controls Y" is a possibility even
when there is *no* parent-child relationship between X and Y. aria-owns
defines a parent child relationship that is not identified by a DOM
parent/child relationship. We encourage you to review
http://www.w3.org/WAI/PF/aria-practices /20091214/#relations_owning which
is devoted to providing guidance on using aria-owns and aria-controls. At
this point we believe the specification and the best practices guide, when
viewed together, provide adequate guidance on the use of both
relationships.
----------------------------------------------------------------------
Comment 144: Clarify dropeffect
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-dropeffect (state) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-dropeffect>
Status: Accepted proposal
-------------
Your comment:
-------------
Drop-effect means what functional thing happens, right? Not a visual effect
like a glow? Please clarify this in the short definition, instead of only
in the full description.
--------------------------------
Response from the Working Group:
--------------------------------
We agree that more information should be provided. We are making the
following change:
<change>
Indicates the effect of a drag-and-drop operation when the dragged object
is released on the drop target.
</change>
<to>
Indicates what functions can be performed when the dragged object is
released on the drop target. This allows an assistive technology to convey
the possible drag options available to them including whether a pop-up menu
of choices is provided by the application. Typically, drop effect functions
can only be provided once an object has been grabbed for a drag operation
as the drop effect functions available are dependent on the object being
dragged.
</to>
----------------------------------------------------------------------
Comment 145: flowto and tab order
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-flowto (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-flowto>
Status: Answered question
-------------
Your comment:
-------------
We are concerned that authors will generate inconsistent aria-flowto order
and tab order. Could the default tab order follow the flowto order?
--------------------------------
Response from the Working Group:
--------------------------------
aria-flowto could be be aligned with the taborder, but in actual fact that
would defeat the purpose of it.
aria-flowto is designed to:
- provide an AT navigation path that is beyond the normal DOM structure
navigation order when the normal navigation order will not suffice.
- provide a vehicle to specify alternative paths to take which is beyond
the scope of tabindex. So, for say flow diagram or a multiplexor in a
drawing you can specify different paths to choose from based on the
aria-flowto property. The AT can then assist the user in choosing which
path to take by providing the options and then moving the focus to them.
These uses cases are articulated in the ARIA Best Practices Guide:
http://www.w3.org/WAI/PF/aria-practices/20091214/#relations_flowto
----------------------------------------------------------------------
Comment 146: aria-hidden vs CSS hidden
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-hidden (state) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-hidden>
Status: Alternate action taken
-------------
Your comment:
-------------
Why do have the aria-hidden attribute instead of just using css hidden? It
allows the possibility of getting the two states out of synch.
--------------------------------
Response from the Working Group:
--------------------------------
The reason for having aria-hidden is for assistive technologies or user
agents, which access the DOM, to disambiguate various potential sources of
information that an area of the DOM is hidden. It is sometimes difficult
for AT to ascertain whether content visibly hidden with CSS (e.g., a
negative position or negative text indent) is also intended to be hidden
from all users. By indicating that it is hidden in the DOM, the screen
reader can skip that content. For details see:
http://www.w3.org/WAI/PF/aria-practices/20091214/#ContentPresChanges in the
ARIA Authoring Practices Guide.
Since this was not clear we have made the change to the aria-hidden
definition:
<change>
This allows the assistive technology to properly skip hidden elements in
the document.
</change>
<to>
Some assistive technologies access WAI-ARIA information directly through
the DOM and not through platform accessibility supported by the browser.
Authors SHOULD set aria-hidden="true" on content that is not displayed,
regardless of the mechanism used to hide it. This allows the assistive
technology or user agents to properly skip hidden elements in the
document.
<to>
----------------------------------------------------------------------
Comment 147: Strengthen UA response to invalid
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-invalid (state) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-invalid>
Status: Accepted proposal
-------------
Your comment:
-------------
For aria-invalid, we suggest revising the second sentence of paragraph 2 to
say "User agents MUST inform the user of the error." This would make it
more consistent with WCAG 2 SC 3.3.1 and would give an author more
confidence in the ability to use and rely on this state.
--------------------------------
Response from the Working Group:
--------------------------------
Most OS platforms provide for state and property change event notification.
Therefore, for such notification to be made accessible, all that is
required is that the assistive technology (and, by extension, the user) is
notified of state changes, which means that state and property information
MUST be passed directly to the platform's OS for immediate use by an AT.
For example, IAccessible2 1.0.2 provides a property change event
(IA2_EVENT_OBJECT_ATTRIBUTE_CHANGED) when invalid is set in FF. For more
information about state and property changes, please consult the User Agent
Implementation Guide requirement that a user agent notify an assistive
technology when aria-invalid changes.
----------------------------------------------------------------------
Comment 148: Label vs title
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-label (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-label>
Status: Accepted proposal
-------------
Your comment:
-------------
Does aria-label replace @title? And should it always be styled as
display:none?
--------------------------------
Response from the Working Group:
--------------------------------
No. aria-label is not a replacement for title. It will take precedence over
@title in the accessible name computation. You should use it when you need
an accessible name that does not impact the tooltip or when you are not
using an aria-labelledby property to label an object. aria-label is a
WAI-ARIA property representing the text name equivalent of an element.
Consequently, there are no specific styling requirements.
To see how the accessible name is computed by a user agent (note there
will be some slight modifications to this resulting from last call
comments) please refer to:
http://www.w3.org/WAI/PF/aria/20091214/roles#textalternativecomputation. As
you can see, aria-label takes precedence over @title in the name
computation as it was the author's intent to use this over the title or a
separate label.
Based on your comments regarding "hidden" we clarify its definition:
<change>
Defines a string value that labels the current element.
</change>
<to>
Defines a string value that labels the current element when included as an
attribute of the current element.
</to>
We will also add a note to the description of aria-label:
Note: aria-label is similar to @title in HTML, but does not generate a
visible tooltip.
----------------------------------------------------------------------
Comment 149: User control of live regions
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-live (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-live>
Status: Proposal not accepted
-------------
Your comment:
-------------
The spec should suggest that AT needing provide users a way to configure
what to do with live regions. For example, users should be able to say that
all liveregions from doubleclick.com will be treated as polite, regardless
of how they are marked up. This capability should be configurable based on
URL, among other things. Perhaps this should be addressed in the User Agent
Implementors Guide.
--------------------------------
Response from the Working Group:
--------------------------------
Currently, the user agent implementation guide does not require that user
agents provide a way to override politeness levels for a site. We agree
this may, in fact, be useful but would not want to mandate it in the User
Agent Implementation Guide as it also should be handled by an assistive
technology. The intent is for the User Agent Implementation Guide to be
normative and we do not believe this should be a normative implementation.
----------------------------------------------------------------------
Comment 150: Key behavior in text area
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-multiline (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-multiline>
Status: Answered question
-------------
Your comment:
-------------
The behavior of pressing the Enter key is inconsistent for textarea
controls. (Sometimes it submits the form.) Would aria-multi-line need to be
consistent with that behavior? Or is this something that should be changed
in browser support for HTML?
--------------------------------
Response from the Working Group:
--------------------------------
The WAI-ARIA specification does not specify keyboard interaction. The
aria-multiline property simply states that the text box can span multiple
lines.
If the enter key in a text area causes a form to submit this would appear
to be a browser problem as the enter key should result in creating the
equivalent of a carriage return line feed and place the user at the next
line of text. What you suggest is an accessibility issue for HTML
supporting browsers as the user should know if an action is going to submit
a form. A user could inadvertently initiate an unintended purchase.
We will, however, will add a note to the spec to make authors aware of the
subtle difference between text fields and text areas.
----------------------------------------------------------------------
Comment 151: Clarify relevant vs atomic
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-relevant (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-relevant>
Status: Accepted proposal
-------------
Your comment:
-------------
What's the difference between aria-relevant and aria-atomic? How does an
author know which to choose? This is explained in the Best Practices guide,
but should be addressed in the spec.
--------------------------------
Response from the Working Group:
--------------------------------
We agree the definitions of aria-relevant and aria-atomic should be more
specific. Consequently, we shall enhance them to separate which property
specifies the relevant change notification and which specifies how to
present those changes.
----------------------------------------------------------------------
Comment 152: Clarify autocomplete none
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-autocomplete (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-autocomplete>
Status: Accepted proposal
-------------
Your comment:
-------------
"none: Only values from the value list can be selected." - what value list
is this? Is this referring to a combobox? What does "none" mean for a
simple text box?
--------------------------------
Response from the Working Group:
--------------------------------
We have changed the default value for none to mean that no input completion
suggestions are provided.
----------------------------------------------------------------------
Comment 153: Impact of not live
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-live (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-live>
Status: Answered question
-------------
Your comment:
-------------
If aria-live is set to "off," what is the expected UA behavior in terms of
overriding this setting? An author's use of this property might conflict
with WCAG 2.0 4.1.2 (... and notification of changes to these items is
available to user agents, including assistive technologies).
--------------------------------
Response from the Working Group:
--------------------------------
The user agent simply maps that aria-live property and its value to the
assistive technology as it does for all the other aria-live values. It is a
recommendation to the AT to not present updates to the region. The user
agent suppresses no notifications of any kind. It is up to the AT to decide
what to present. There is no violation of this checkpoint. For details on
the of aria-live property mapping please see the User Agent Implementation
Guide: http://www.w3.org/WAI/PF/aria-implementation/20091214/.
Currently, there is no vehicle for an author to indicate to an assistive
technology that changes to a region should be ignored. Without the value of
aria-live="off" the assistive technology has no way of ascertaining this
information. This value also helps an assistive technology from presenting
something to the user that may be an annoyance.
----------------------------------------------------------------------
Comment 154: Multiple owners
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-owns (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-owns>
Status: Accepted proposal
-------------
Your comment:
-------------
We assume that the ids are a list of elements that should be considered
children of the current element. Is it an error if more than one elements
"owns" another element? Is the element removed from its position implied by
the dom hierarchy, and is the user agent responsible for implementing that
(lack of) relationship?
--------------------------------
Response from the Working Group:
--------------------------------
We agree that the description of aria-owns needs to be more explicit.
aria-owns is a pointer (like a symlink) to another part of the
accessibility tree. The hierarchy of the DOM tree and the accessible tree
remain untouched. aria-owns provides additional relationship information
that is published to the accessibility API and may be used by assistive
technology.
We shall make the following changes:
Action for spec, append the following to #aria-owns:
"Authors MUST ensure that an element's IDREF is not specified in more than
one other element's 'aria-owns' attribute at any time. In other words, an
element can have only one explicit owner."
Action for UAIG:
"User Agents MUST expose DOM children as primary children in the
accessible tree, and MAY expose children specified by @aria-owns as a
secondary relationship. User agents SHOULD retain the order of explicitly
'owned' children elements as specified by the author using the order of
IDREFs in the @aria-owns attribute."
----------------------------------------------------------------------
Comment 155: Default for relevant
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-relevant (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-relevant>
Status: Proposal not accepted
-------------
Your comment:
-------------
How does the aria-relevant property relate to SC 4.1.2? If an author
decides that they want to include a live region with scrolling headlines,
it sounds like the default (when an author does not specify this state) is
to assume that removal of an item does not need to be available to the
UA/AT. What mechanisms are in place to help keep users from being confused
about things that may have changed since they first read them? To minimize
confusion, please consider changing the default behavior to assume that
this type of change is relevant.
--------------------------------
Response from the Working Group:
--------------------------------
aria-relevant states that the default is to tell the assistive technology
that they should listen for nodes to be added or for text to be added to or
removed from the DOM in a live region.
What is recommended is that authors avoid specifying to the AT that
removals are relevant as this often represents unwanted interruptions and
impacts an AT's performance. Exceptions should be things like buddy list
name removals.
So, we believe that the text addresses your concern.
----------------------------------------------------------------------
Comment 156: Location of setsize
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-setsize (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-setsize>
Status: Proposal not accepted
-------------
Your comment:
-------------
"This property is marked on the members of a set, not the container element
that collects the members of the set." why? Setting this value on every
element in the set will be very expensive for large sets, and introduces
the possibility of inconsistent values, particularly if the set changes
size dynamically. It doesn't seem like the user agent/AT overhead of
retrieving the set size from the aria parent element is so onerous.
--------------------------------
Response from the Working Group:
--------------------------------
While we agree that it would be more efficient for the developer to place
aria-setsize on the container it would be less efficient for assistive
technologies like screen readers. The alternative is to have the assistive
technology always go back to the ancestor with the container role and ask
for the aria-setsize. For performance reasons we have been asked by a
significant screen reader vendor to place the setsize on the element as it
will be processed by the assistive technology.
We would like to point out that by default if these properties are not
provided the user agent will compute and set this property on supporting
roles based on the assumption that all elements in the list are in the DOM.
So, it is only in those cases when all the elements in the list are not in
the DOM that this additional work is required by the author.
For these reasons we will be staying with our decision to require
aria-setsize to be place on each member of the set.
----------------------------------------------------------------------
Comment 157: WCAG Principles not to satisfy
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 9.2. Glossary <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#Terms>
Status: Accepted proposal
-------------
Your comment:
-------------
Definitions for "Keyboard Accessible," "Perceivable" and "Operable" include
the language "... indicate required satisfaction of.." (GL 2.1, Principle
2, Principle 1, respectively). Technically, none of these are things you
satisfy directly within WCAG 2. Unless the intent was to highlight specific
WCAG 2.0 requirements, suggest that the language be generalized (ex.
"references in this document relate to...").
--------------------------------
Response from the Working Group:
--------------------------------
We have made this change.
----------------------------------------------------------------------
Comment 158: Exapnd AT definition
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 9.2. Glossary <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#Terms>
Status: Accepted proposal
-------------
Your comment:
-------------
Add "Onscreen keyboards" to the bulleted list of examples of AT in the
definition of Assistive Technology.
--------------------------------
Response from the Working Group:
--------------------------------
We have added on-screen keyboards to the list of "alternate keyboards"
included in the definition.
----------------------------------------------------------------------
Comment 159: Define "literal"
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 9.2. Glossary <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#Terms>
Status: Proposal not accepted
-------------
Your comment:
-------------
For designers, define "literal" in the definition of "Value"
--------------------------------
Response from the Working Group:
--------------------------------
"Literal" is a recognized term in computer science. For those who are not
well-versed in this language, such as designers, the nuances of "literal"
vs. "value" are not salient to the overall text.
Perhaps more importantly, the only really good word we can use here to
describe "value" without using "value" itself. We have chosen to leave the
definition as is.
http://en.wikipedia.org/wiki/Literal_%28computer_science%29
----------------------------------------------------------------------
Comment 160: AT
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0063.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 8.4. Assistive Technology <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#AT_supp>
Status: Accepted proposal
-------------
Your comment:
-------------
This section needs to be fleshed out a lot. Rich and Cynthia gave a
presentation at ATIA about this and gathered some feedback. They have
concrete recommendations to make.
--------------------------------
Response from the Working Group:
--------------------------------
We have revamped this section to better explain programmatic access to a
broad range of assistive technologies.
Received on Tuesday, 15 December 2009 00:34:32 UTC