RE: ISSUE-109: aria-section-title - Straw Poll for Objections

RE: 3. Objections to the Change Proposal to change the title and provide
advice discouraging conflicting semantics

 

We have a Change the title of the Annotations for Assistive Technologies
section, add more introductory material, and urge implementors to avoid
exposing conflicting semantics in their user interface.. If you have
strong objections to adopting this Change Proposal specifically with
respect to the figure element, please state your objections below.

 

 

(Observation/question:  what does ".specifically with respect to the
figure element, please state your objections below." have to do with this
proposal? I will work under the assumption that this is a typographical
error)

 

Response:

 

Re:

"SUMMARY

Change the title of the Annotations for Assistive Technologies section,
add more introductory material, and urge implementors to avoid exposing
conflicting semantics in their user interface.

 

RATIONALE

The term ARIA is an acronym with very little name recognition in the wider
developer community, and using it in a heading is likely to confuse people
rather than encourage them to learn more. "

 

I *STRONGLY* (in the most emphatic of ways) OBJECT to the editor seeking
to rename references to an existing W3C technology/Recommendation simply
on the grounds that he thinks it should be named differently. 

 

The proper name of the current W3C Working Draft is: Accessible Rich
Internet Applications (WAI-ARIA) http://www.w3.org/TR/wai-aria/ 

 

Suggesting that ARIA or (WAI-ARIA) in the context of today's modern web
development has little name recognition in the wider community is both
unsubstantiated and ludicrous. In fact typing WAI-ARIA into Google and
hitting the "I'm Feeling Lucky" button pays off the jackpot - you arrive
at the W3C WAI-ARIA overview page, where you can learn what you are
allegedly not already knowing, have links to the current working draft,
etc. Most contemporary web-content developers today would have to actively
seek to *not* know what ARIA is. [1]

 

 

Specific to the 3 proposed actions noted in this Change Proposal:

 

1. "Change the heading to just "Annotations for assistive technology
products", which accurately describes the purpose of the section without
using any acronyms."

 

 

I *STRONGLY OBJECT* to this proposal.  ARIA attributes are *NOT*
Annotations, they are attributes, and precision and accuracy should be
important in all Official Recommendations, Specifications and other
Technical Notes emerging from the W3C.

 

Annotations: 

Function: noun 

Date: 15th century

1 : a note added by way of comment or explanation

http://www.merriam-webster.com/dictionary/annotations 

 

Attributes:

      Function: noun 

Date: 14th century

1 : an inherent characteristic

http://www.merriam-webster.com/dictionary/attributes 

 

As Steve Faulkner points out in his Change Proposal
(http://www.w3.org/html/wg/wiki/ChangeProposals/ariasection), WAI-ARIA can
be useful for more than just assistive technology. (See also: Apple's iOS
4 supports WAI-ARIA landmarks < Marco's accessibility blog:

www.marcozehe.de/2010/.../apples-ios-4-supports-wai-aria-landmarks/)

 

Perpetuating an ethos of ghetto-ization is something that the W3C should
be very wary of. While I can see a change of title being useful, it should
focus on the name recognition factor of WAI-ARIA and speak in terms of
Enhanced Accessibility for all users, and not in terms of Adaptive
Technology (in the same way we speak of User Agents rather than Browsers).
If pressed for an alternative, I personally would suggest: "Accessible
Rich Internet Applications (WAI-ARIA) for improved accessibility" because,
frankly, that is what the section is about.

 

 

 

2. "Add an introductory paragraph that explains what ARIA is before using
the acronym. The exact text is left to editor discretion, but it should
include an expansion of the acronym, an explanation of the purpose of the
technology, and could include an example."

 

While it may indeed be useful to expand upon what WAI-ARIA is, for those
few who may yet to have encounter it, by providing an explanatory sentence
or paragraph and expanding the acronym when first introduced, I *STRONGLY*
DISAGREE with leaving "the exact text" to the editor. The current WAI-ARIA
Working Draft has an excellent opening paragraph that could be easily
re-purposed here:

 

      "Accessibility of web content requires semantic information about
widgets, structures, and behaviors, in order to allow assistive
technologies to convey appropriate information to persons with
disabilities. <del>This specification</del><ins>WAI-ARIA</ins> provides an
ontology of roles, states, and properties that define accessible user
interface elements and can be used to improve the accessibility and
interoperability of web content and applications. These semantics are
designed to allow an author to properly convey user interface behaviors
and structural information to assistive technologies in document-level
markup."

 

In the interest of cohesiveness, clarity and ensuring that the intent of
that specification's authors and contributors is carried forward, *NOTHING
BUT* this text should be contemplated, else the editor's impression of
what WAI-ARIA is/isn't and does/doesn't-do might not match that of the
original authors. (Given the apparent state today regarding the editor's
confusion over the fact that WAI-ARIA are attributes and not annotations,
this is a well founded concern)

 

 

 

3. Add a requirement that user agents not let their behaviour other than
as exposed through assistive technologies be affected by ARIA annotations
when those annotations conflict with HTML semantics. The exact text is
again left to editor discretion.

 

I *STRONGLY OBJECT* to this proposal. How will browsers know when Adaptive
Technology is being used? What of applications such as Apple's Voice Over,
which is not an external Adaptive Technology, but rather a basic feature
of Apple's OSes? Browsers will continue to map HTML constructs to the OS's
Accessibility API regardless of whether AT is present or not, and what is
being sent to the Accessibility API should always be the definitive
behavior. (My reading here is that somehow the editor wants to create 2
"streams" of the DOM, one which is mapped to the accessibility API, the
other directly outputted to the screen in some bizarre form of Orwellian
"All animals are created equal, but some are more equal than others"
behavior.)  

 

This proposed requirement has little thought behind it (but again seeks to
create a divide between those without disabilities and those with); it has
no practical explanation of how this would be implemented. The majority of
Adaptive Technology cannot be determined by the browser, as to do so would
require that the browser have the ability to examine every aspect of the
end user's hardware and software system. The security and privacy
implications of that are mind-boggling, and no proof that this can even be
achieved has been put forward in the Change Proposal.

 

***************

 

[1] Recent developments suggest that the Chairs, when evaluating poll
results, want specific and detailed proof of assertions. To that end,
entering WAI-ARIA into Google returned back to me (on Aug. 13, 2010) the
following results:

 

(more than 10 pages of results returned)

 

WAI-ARIA Overview

      Dec 15, 2009 ... WAI-ARIA, the Accessible Rich Internet Applications
Suite, defines a way to make Web content and Web applications more
accessible to people ...

www.w3.org/WAI/intro/aria 

 

Accessible Rich Internet Applications (WAI-ARIA) 1.0 

      WAI-ARIA was previously published as a Last Call Working Draft. Due
to substantial changes in response to these comments, PFWG decided to
return to Working ...

www.w3.org/TR/wai-aria/ 

 

WAI-ARIA - Wikipedia, the free encyclopedia

      WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet
Applications) is a draft technical specification published by the World
Wide Web ...

http://en.wikipedia.org/wiki/WAI-ARIA   

 

A List Apart: Articles: Accessible Web 2.0 Applications with WAI-ARIA

      Roles come in two flavors: XHTML and WAI - ARIA . A basic set is
defined in the XHTML 1.1 Role Attribute Module. It is extended by the WAI
- ARIA Role RDF ...

www.alistapart.com/articles/waiaria 

 

Web 2.0 Accessibility with WAI-ARIA FAQ - CodeTalks

      Sep 30, 2009 ... Here is a useful answer from Henri Sivonen
(including a link to the Validator.nu prototype with WAI-ARIA support):
...

http://wiki.codetalks.org/.../Web_2.0_Accessibility_with_WAI-ARIA_FAQ  

 

Introduction to WAI ARIA - Opera Developer Community

      Aug 1, 2008 ... Opera Developer Community article by Gez Lemon,
serving as an introduction for those who are new to Accessible Rich
Internet Applications ...

http://dev.opera.com/articles/view/introduction-to-wai-aria/  

 

Using WAI-ARIA Roles and States with the YUI Menu Control > Yahoo ...

      Dec 21, 2007 ... The WAI-ARIA Roles and States can be applied to a
YUI Menu instance regardless of whether it is built using existing markup
on the page, ...

www.yuiblog.com/blog/2007/12/21/menu-waiaria/ 

 

The Paciello Group Blog > HTML5 and the myth of WAI-ARIA redundance

      Apr 8, 2010 ... Will HTML5 make the use of WAI-ARIA in HTML
redundant? the short answer is definitely not. There are many ARIA roles
and properties that are ...

www.paciellogroup.com/blog/?p=585 

 

Apple's iOS 4 supports WAI-ARIA landmarks < Marco's accessibility blog

      Jun 22, 2010 ... Once enabled, and the user switches to it via the
rotor gesture, navigating by WAI-ARIA landmarks on a page works very
nicely. ...

www.marcozehe.de/2010/.../apples-ios-4-supports-wai-aria-landmarks/