- From: Janina Sajka <janina@rednote.net>
- Date: Tue, 15 Dec 2009 00:33:44 +0000 (GMT)
- To: Anne van Kesteren <annevk@opera.com>
- CC: PFWG Public Comments <public-pfwg-comments@w3.org>
Dear Anne van Kesteren:
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 11: Introduction, Figure 1.0 (editorial)
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0000.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 1. Introduction <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#intro>
Status: Accepted proposal
-------------
Your comment:
-------------
The introduction states "Figure 1.0 illustrates a typical Document Object
Model (DOM) [DOM] node." but Figore 1.0 does not really illustrate a DOM
node at all.
--------------------------------
Response from the Working Group:
--------------------------------
We agree the requires greater clarification and will change "Figure 1.0
illustrates a typical Document Object Model (DOM) [DOM] node." to "Figure
1.0 illustrates the relationship between user agents, accessibility APIs,
and assistive technologies." (and move the DOM node term reference link to
the reference in the second sentence)
----------------------------------------------------------------------
Comment 12: abstract roles
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0001.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.1. Abstract Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#isAbstract>
Status: Accepted proposal
-------------
Your comment:
-------------
If abstract roles are not at all exposed by AT and not expected to be
supported it makes more sense to simply forbid authors to use them so
validators will flag their use, etc. I.e. use MUST NOT rather than SHOULD
NOT in section 4.2.1.
--------------------------------
Response from the Working Group:
--------------------------------
We have changed the requirement to state that authors MUST NOT use abstract
roles, and that conformance checkers should raise an error. We are also
adding to the User Agent Implementation Guide error handling procedures for
abstract and unknown roles, that they ignore the role.
----------------------------------------------------------------------
Comment 13: Name Computation
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0003.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.7.1. Name Computation <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#namecomputation>
Status: Alternate action taken
-------------
Your comment:
-------------
Two comments:
1. It does not define how to concatenate the results. Simple string
concatenation?
2. "text equivalents for nodes" is not linked. Would be nice if that was
consistently done.
--------------------------------
Response from the Working Group:
--------------------------------
The entire text equivalent calculation section has been reworded and these
issues were clarified in that rewording.
----------------------------------------------------------------------
Comment 14: Parent element
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0004.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.6. Parent Element <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#scope>
Status: Accepted proposal
-------------
Your comment:
-------------
Several comments on this section (4.2.6):
1. From the definition it sounds like this section should be titled
"Ancestor element" since the element can be a descendant rather than just
a child.
2. It is not clear to me why SHOULD is used here rather than MUST.
3. The "For example" sentence contains a normative requirement.
4. "contained inside (or owned by)" can simply be "owned by" since
that
definition already talks about descendants.
5. "owned by" with the relevant pointer to "owned" should probably be
somewhere in the normative definition.
--------------------------------
Response from the Working Group:
--------------------------------
Taking the parts of your comment in turn:
1. We will retitle to the section as "Required Context Element" for
clarity.
2. We have changed this to a MUST requirement.
3. We will remove the RFC2119 language from the example paragraph.
4 and 5: We will move the reference to "owned element" out of the example
into the main prose, and update the wording of the example accordingly.
----------------------------------------------------------------------
Comment 15: Text Equivalent Computation
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0005.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: Proposal not accepted
-------------
Your comment:
-------------
This algorithm (section 4.2.7.3) has many issues:
1. "hidden" is not defined. In the DOM nothing is hidden. I'm assuming
you might mean not visible on screen, but that is a very hard concept to
define and implement. This needs to be far more concrete to be
implemented.
2. The use of DOM attributes is inconsistent with HTML5. Simply using
attributes would suffice here I think and be more clear.
3. The third bullet point of 2A is not clear at all and saying it is
covered by the "appropriate specification for that markup" is not true.
HTML4 or HTML5 does not cover what seem to be hinting at here.
4. "Additional contribution of user-entered data" needs a much more
precise definition as well. "appended after" is also not particularly clear
here.
5. 2C leads to infinite recursion in this scenario:
<span id="a">
<span aria-describedby="b">X</span>
</span>
<span id="b">
<span aria-describedby="a">X</span>
</span>
and something points to either #a or #b if I'm reading this
correctly.
6. 2D is also not very clear. What to do for SVG where tooltips can
contain markup?
7. Point 3 is even less clear. List style bullets are not generated text.
Whitespace normalization needs to be defined here.
In general this algorithm seems very much over engineered for something
that should be very simple. Getting this interoperably implemented is a
gigantic task for very little benefit so it is unlikely it will ever
happen. Also, I thought this draft was not about implementation
requirements?
--------------------------------
Response from the Working Group:
--------------------------------
> This algorithm (section 4.2.7.3) has many issues:
>
> 1. "hidden" is not defined. In the DOM nothing is hidden. I'm
> assuming you might mean not visible on screen, but that is a
> very hard concept to define and implement. This needs to
> be far more concrete to be implemented.
We have added a definition of "hidden" to the glossary
(http://www.w3.org/WAI/PF/aria/20091214/terms#def_hidden). In brief, a
hidden element is one that is not visible nor perceivable to *any* user.
Use of aria-hidden or CSS visibility:hidden, and display:none mark an
element as hidden, as does use of aria-hidden="true".
> 2. The use of DOM attributes is inconsistent with HTML5. Simply
> using attributes would suffice here I think and be more clear.
The distinction between DOM attributes and content attributes is
tangential to the use of "DOM attributes" in the spec. Our use of "DOM
attributes" is in the sense of what the functions setAttribute() and
getAttribute() access as defined in the DOM IDL for Elements
(http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/idl-definitions.html).
However, since removing "DOM" from the sentence doesn't detract from its
clarity, and might actually enhance it, we are willing to do so. Note that
there is a link from the word "attributes" to its glossary entry.
> 3. The third bullet point of 2A is not clear at all and saying it
> is covered by the "appropriate specification for that markup" is
> not true. HTML4 or HTML5 does not cover what seem to be hinting
> at here.
Bullet 3 could be clearer. We will rewrite it.
> 4. "Additional contribution of user-entered data" needs a much
> more precise definition as well. "appended after" is also not
particularly clear here.
The intent of rule 2B is to handle a specific case where a label on a
widget contains an embedded control. Furthermore, the embedded control is
multi-valent and set by the user (hence, "user-entered data"). An example
is a label on a checkbox where part of the label is a text field:
[X] Flash the screen [input] times
Here, "[input]" is a number entered by the user. If the user has entered
"5", the complete label is "Flash the screen 5 times".
We will reword the section to clarify the issue.
> 5. 2C leads to infinite recursion in this scenario:
>
> <span id="a">
> <span aria-describedby="b">X</span>
> </span>
>
> <span id="b">
> <span aria-describedby="a">X</span>
> </span>
We are adding a constraint to the User Agent Implementation Guide that the
algorithm must track "visited" nodes, and if a node has been visited, not
to process it a second time. In your example, this would mean that once
<span id="a"> has been consulted, if directed there again by the
aria-describedby child of <span id="b">, it immediately returns and does
not process "a" again. The resulting text equivalent is the "X" from span
"a", and the X from span "b": "X X".
> 6. 2D is also not very clear. What to do for SVG where tooltips
> can contain markup?
The text equivalent that is generated by this algorithm is plain text.
Any markup would be filtered out. For example, "<p>This is
<em>excellent</em> chocolate cake</p>" gives the string, "This is excellent
chocolate cake". This works like the innerText property in HTML.
> 7. Point 3 is even less clear. List style bullets are not
> generated text. Whitespace normalization needs to be defined
> here.
There is a note re: whitespace normalization following point 3. Is that
sufficient? We are rewording that note to read:
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
trimmed of white space and "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.
----------------------------------------------------------------------
Comment 16: 4.3.1 Base Types
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0006.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.3.1. Base Types <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#taxonomic>
Status: Accepted proposal
-------------
Your comment:
-------------
The note includes a normative requirement. That makes no sense. (Again, it
should probably say MUST NOT, but not in a note.)
--------------------------------
Response from the Working Group:
--------------------------------
We have agreed that RFC 2119 statements do not belong in notes. We will
reword appropriately to move RFC 2199 statements out of notes.
----------------------------------------------------------------------
Comment 17: 4.4. Definition of Roles
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0007.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:
-------------
This again has a note with a conformance requirement. I suggest to go
through the entire specification and clean this up. I won't comment on such
instances any further.
--------------------------------
Response from the Working Group:
--------------------------------
We have agreed that RFC 2119 statements do not belong in notes. We will
reword appropriately to move RFC 2199 statements out of notes.
----------------------------------------------------------------------
Comment 18: 5.2.4 Value
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0008.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.2.4. Value <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#propcharacteristic_value>
Status: Alternate action taken
-------------
Your comment:
-------------
I think for authors it would make much more sense here to reuse datatypes
from HTML or SVG.
Speficially NMTOKENS and IDREFS do not work as described in HTML context
because HTML does not do whitespace normalization of attribute values.
Neither does the DOM for that matter. E.g.
aria-labelledby="a
b"
does not match the IDREFS production. It is highly unlikely anyone would
implement it that way though and it is also confusing to authors because
e.g.
headers="a
b"
does work perfectly fine and as expected.
Similar attributes that take "true" and "false" as values in HTML such as
contenteditable="" and spellcheck="" also take the empty string (meaning
true) and match in an ASCII case-insensitve way. They do not take 0 and 1
as allowed values. I think it would be much better to align with that.
--------------------------------
Response from the Working Group:
--------------------------------
We have made ARIA attribute types abstract without inherent formats. Host
languages would use corresponding types from that language for each ARIA
type. We are providing a recommended mapping from the abstract types in
ARIA to concrete types in known host languages. In this way, attribute
value syntax and processing rules come from the host language, not the ARIA
specification.
Note that our recommended mappings for HTML are fairly straightforward,
except that ARIA boolean attributes are token attributes (accepting values
of "true" and "false", not HTML boolean attributes (where false can only be
declared by omitting the attribute). This is because of the way these
attributes have already been implemented and for greater portability
between host languages.
----------------------------------------------------------------------
Comment 19: 6.1.1. Role attribute
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0009.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 6.1.1. Role Attribute <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#host_general_role>
Status: Alternate action taken
-------------
Your comment:
-------------
Comments:
1. "The attribute value MUST allow a space-separated sequence of
whitespace-free substrings;" needs a better definition.
2. In case of <input type=checkbox role=radio> I think we do not want the
role to be honored so the WAI-ARIA specification should not require that.
3. Also, the WAI-ARIA specification does not define how roles are to be
processed.
--------------------------------
Response from the Working Group:
--------------------------------
1. The issue of whitespace-separated string is addressed by relegating
attribute processing rules to host languages, as explained in the response
to one of your earlier comments.
2. Although we can understand that there are certain host language
elements that it would be strange or undesirable to override with ARIA
markup, the purpose of ARIA is to provide semantics to accessibility APIs
in unusual cases. An example like <input type="checkbox" role="radio" />
would indeed be an odd choice, and we expect it would be rare. However, if
the author did have a reason to use this design pattern, it would be
important for the ARIA role to be observed. We have clarified the
explanation of this. Also, while we think it is important for ARIA role
always to take precedence, we do think ARIA states and properties that
conflict with host language attributes should be ignored and have
introduced this option.
http://www.w3.org/WAI/PF/aria/20091214/host_languages
3. We are now normatively referencing the WAI-ARIA User Agent
Implementation Guide. This defines how roles should be processed.
----------------------------------------------------------------------
Comment 20: 6.1.2 State and Property Attributes
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0010.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 6.1.2. State and Property Attributes <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#host_general_property>
Status: Accepted proposal
-------------
Your comment:
-------------
"When these attributes appear in a document instance, the attributes MUST
be processed as defined in this specification." is fine if the
specification actually defined how the attributes are to be processed in
detail, but it does not do that.
--------------------------------
Response from the Working Group:
--------------------------------
What is not clear is that this document defines what states and properties
are applicable to what host language elements and with or without roles
being applied. Beyond this the ARIA Implementors Guide(s) indicate how they
are mapped to the accessibility API. This is based on the platform
accessibility API implemented by the browser. We will clarify that in our
modification to 6.1.2.
<change>
"When these attributes appear in a document instance, the attributes MUST
be processed as defined in this specification." is fine if the
specification actually defined how the attributes are to be processed in
detail, but it does not do that.
<change>
<to>
When these attributes appear in a document instance, they SHOULD be mapped
to the browser-supported platform accessibility API, as defined by the
WAI-ARIA implementers guide, if they are applicable to supporting host
language elements and roles as defined by this specification.
</to>
----------------------------------------------------------------------
Comment 21: 6.1.4. Resolving Conflicts with Host Languages
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0011.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 6.1.4. Resolving Conflicts with Host Languages <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#host_general_conflict>
Status: Accepted proposal
-------------
Your comment:
-------------
Why is this exactly? It seems that in a number of cases this can have
adverse effects.
--------------------------------
Response from the Working Group:
--------------------------------
We understand that there are situations in which ARIA can cause uncertainty
in processing. We particularly see that ARIA states and properties could
get out of sync with similar host language features (e.g., HTML "checked"
and ARIA "aria-checked").
To resolve this, we describe the concept of "implicit ARIA semantics" -
host language features that are substantially similar to an ARIA feature.
For ARIA states and properties, user agents are instructed to respect the
host language feature, not the ARIA one.
For roles, however, we have determined that it is best to continue to
require that the ARIA role always trump the host language feature. There
may be situations in which this is not optimal, but in order to provide the
author with the ability to provide semantics regardless of issues with host
language semantics, we think this is crucial.
Host languages can define "strong native semantics" that should not be
overridden by ARIA. Authors are asked to respect this, and conformance
checkers can raise errors or warnings. Nevertheless, user agent behavior is
as described above.
----------------------------------------------------------------------
Comment 22: 7.1. Non-interference with the Host Language
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0012.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 7.1. Non-interference with the Host Language <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#ua_noninterference>
Status: Alternate action taken
-------------
Your comment:
-------------
How is this section different from section 6.1.4?
--------------------------------
Response from the Working Group:
--------------------------------
This is a directive to an assistive technology to chose ARIA markup
semantics over that of the host language. It is not a statement regarding
the interference of the processing of the host language by the user agent.
To clarify this we have added a note to 6.1.4.
----------------------------------------------------------------------
Comment 23: 7.2. All WAI-ARIA in DOM
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0013.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 7.2. All WAI-ARIA in DOM <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#ua_dom>
Status: Accepted proposal
-------------
Your comment:
-------------
The requirement in this section is redundant with requiring a DOM
implementation in the first place. I.e. a conforming DOM implementation
exposes all attributes and values as they are in syntax.
--------------------------------
Response from the Working Group:
--------------------------------
We agree with your comments. The intent of this section is to ensure that
DOM implementations expose all ARIA properties so that they may be accessed
by an assistive technology. We have clarified this in the spec.
----------------------------------------------------------------------
Comment 24: 7.3. Web Application Notification of DOM Changes
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0014.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 7.3. Web Application Notification of DOM Changes <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#ua_domchanges>
Status: Alternate action taken
-------------
Your comment:
-------------
This section seems to contradict the entire idea that changes are driven by
script from authors and not by the AT. This fundamentally goes against the
whole idea that ARIA is non-intrusive and just an "add-on". Since this is
nowhere else described I assume this is in error and suggest that this
section be removed.
--------------------------------
Response from the Working Group:
--------------------------------
We see this feature as necessary to ensure the robustness of WAI-ARIA and
accessible web applications. However, since DOM mutation events have known
performance considerations, we are modifying the wording to remove specific
mentions to DOM mutation events. Satisfaction of this requirement may be
achieved with DOM mutation event support, or with other future standards
currently in discussion.
----------------------------------------------------------------------
Comment 25: General comments
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0015.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 <http://www.w3.org/TR/2009/WD-wai-aria-20090224/>
Status: Answered question
-------------
Your comment:
-------------
It is very unclear in the draft which requirements apply to authors, which
apply to host languages, which apply to implementors (if any, I thought
this was going to be separate?). It would be nice if that was made much
more clear and if the "conformance" section would introduce the classes of
products properly.
Overall it seems that there is a lot of focus on theory by means of OWL
and RDF which is not actually used in practice (implementations are done by
DTDs, Java code, RNG, C++ at the browser level). This distracts a lot and
makes the specification hard to follow where a simple description of which
roles there are and which properties they take and how they relate would
work much better and use less text. Likewise relying on XML Scheme for
datatypes seems not at all optimal for normal Web authors that eventually
have to grok all this and use it. I think the document could be made a lot
more accessible if it removed these abstract concepts and described itself
more realistically.
WAI-ARIA introduces a lot of concepts based on holes in HTML4 that Web
authors have meanwhile filled using scripting. It would be good if WAI-ARIA
was evaluated again in the light of HTML5. I'm not saying anything needs to
change, but maybe comments could be made on HTML5 on how the two could be
more seamlined. Admittedly I have not reviewed the various roles myself in
depth. Partially because the way they are defined is hard to follow.
--------------------------------
Response from the Working Group:
--------------------------------
We will review the specification for any unclear instances of RFC-2119
requirements. User agent specific conformance will be addressed by the
WAI-ARIA Implementation Guide.
We have discussed the use of RDF/OWL in the past and it was essential that
this be used to ensure that we
had a proper taxonomy that explain the inheritance. If this information
was removed you would lose this knowledge and it would inhibit others from
creating their own taxonomies. RDF/OWL are not used for validation. DTDs
and schemas are designed to validate the markup with the host language. We
are mixing apples and oranges.
When we fully SVG use cases we should extend the existing WAI-ARIA
ontology to address concepts such as maps.
Our evaluation of ARIA in HTML 5 would be limited, as HTML 5 is not
complete and could change, and we don't want to restrict HTML 5
development. We have have received comments from members of the HTML
working group asking us to address specific aspects of HTML 5 and are
working to address them. We also have an HTML 5 task force working with the
HTML working group and have adopted a number of its concepts.
We are moving the various schemata in the appendices to separate pages.
This will make them less up front in the specification and hopefully be
less of a distraction.
----------------------------------------------------------------------
Comment 27: wai-aria vs wai-aria-implementation
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0017.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 <http://www.w3.org/TR/2009/WD-wai-aria-20090224/>
Status: Proposal not accepted
-------------
Your comment:
-------------
In http://www.w3.org/TR/2009/WD-wai-aria-implementation-20090224/ "alert"
and "alertdialog" are always exposed in the same way. "menuitemcheckbox"
and "menuitemradio" are also always exposed in the same way. I haven't
checked the latter two but the former two are very defined in a very
different way in the WAI-ARIA draft. If they cannot be implemented in a
different way this seems unwise because authors will end up using them
interchangeably and we'll never be able to introduce a real difference in
the future because that would break existing deployment. I recommend having
a single role in case AT is not going ot make a difference between the two.
I.e. keep it realistic ;-)
--------------------------------
Response from the Working Group:
--------------------------------
In actual fact, elements marked with role equal to alert and alertdialog
are different in that an alert is not a dialog box and does not require
focus. IAccessible2 and UIAutomation provide a vehicle to gain access to
ARIA roles. UIAutomation has an AriaRole property and IAccessible2 provides
object properties where the actual ARIA roles are available. Both are now
exposed IE 8 and Firefox 3+ respectively.
It is important to understand for ARIA to be accepted we are ensuring an
end to end implementation from markup to browser to AT. Where there is not
a one to one mapping we will ensure that this is addressed in the ARIA User
Agent Implementation Guide.
There are features in ARIA which are not currently supported in all
platform APIs. We hope and expect that some of these features will
eventually be added to APIs. The purpose of the implementation guide is to
document mappings to exisitng APIs, while the ARIA spec is more forward
looking.
Received on Tuesday, 15 December 2009 00:33:54 UTC