- 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