- From: <bugzilla@jessica.w3.org>
- Date: Sat, 25 Jan 2014 15:19:42 +0000
- To: www-validator-cvs@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24394
Bug ID: 24394
Summary: non-ARIA role values are flagged as an error and
should be a warning
Product: Validator (Nu)
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: General
Assignee: mike+validator@w3.org
Reporter: shane@aptest.com
QA Contact: www-validator-cvs@w3.org
The W3C ARIA specification [1] refers to the W3C Role Attribute Recommendation
[2] for the definition of the role attribute. ARIA also defines a collection
of role values that have specific semantics, and only those values are passed
through to underlying accessibility technologies [4]. Therefore, if an element
has <foo role="unknown known" then the role of "known" is the "ARIA role".
Today the validator correctly flags the value of "unknown" in this example as
an error.
However, the Role Attribute Recommendation allows for additional vocabularies
to be defined as long as those vocabularies are scoped as full URIs or as a
CURIE. Consequently, an element like <foo prefix="dc:
http://purl.org/dc/terms/" role="dc:description dc:title known"> is 1) valid
and 2) has a valid ARIA role that would be passed to the underlying
accessibility technology layer.
My request is that the validator either 1) ignore role values that match the
pattern for CURIE or FullURI, or 2) change the current error to a warning - as
in "warning, the values dc:description and dc:title are non-ARIA values, and
will therefore be ignored by ARIA user agents."
(Note - technically the @prefix in the example above is not required, since
there are some prefixes that are automatically defined in the RDFa Initial
Context [3] - it is included for completeness)
[1] http://www.w3.org/WAI/PF/aria/roles
[2] http://www.w3.org/TR/role-attribute/
[3] http://www.w3.org/TR/rdfa-core/Overview.html#s_initialcontexts
[4] http://www.w3.org/1999/xhtml/vocab
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Saturday, 25 January 2014 15:19:45 UTC