[css-counter-styles] PFWG feedback on CSS Counter Styles Level 3

This is feedback from the Protocols and Formats Working Group on CSS
Counter Styles Level 3, Last Call Working Draft of 18 July 2013
http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130718/. PFWG
consensus to send these as group comments is archived at

We have two comments:

Comment 1: Support accessible usages

In general we think it is possible to make accessible content using this
specification. However, we feel that it will not be clear to users how
to make accessible content, and a lot of content that conforms to this
specification may not be accessible. We propose that:

    * It should be a requirement that accessible content alternative is
      provided (when content is inaccessible);
    * All examples in the specification should support accessibility.

For example, it may be be possible, by having a fallback class with the
"speakas" option, to create what is  essentially alt text for symbols.
In cases like this - where symbols represent true information - a text
equivalent fallback class should be not just possible but a requirement.
If it is considered inappropriate to require this we would at least like
it to be best practice.

Comment 2: Accessibility API mapping

It is not clear how user agents (assistive technology and browsers)
should support this specification to provide consistent accessibility
support. Many assistive technology's (AT) work via an accessibility API
(AAPI), where the browser populates a custom data structure in the AAPI
and the AT present that information in the way best suited to the user's
needs. More information on this topic can be found at
http://www.w3.org/TR/wai-aria-roadmap/.
<http://www.w3.org/TR/wai-aria-roadmap/>

At present there is not information for how user agents should should
map CSS features cases to the accessibility API in an interoperable
manner. This means that different browsers will do it differently and
often incorrectly. Hence, the author will not be able to make accessible
content.

We would like specification to specify the mapping of these attributes
and classes to the user agent and accessibility API of the operating
system. This will enable user agents to know how to correctly support
the specification, which would make it much more likely that
accessibility will not just be theoretically supported, but to be
actually and correctly supported by user agents. We are happy to work
with you on how to do these mappings.

There are two other advantages to doing this. Firstly it will also give
us a clear way to determine if and when  user agent support is
sufficient to allow authors to use this specification. FYI, as many
large sites are required to provide accessible content, and then
accessibility support for real users is a legal requirement. In such
cases authers will not be alowecd to adopt this specification becuse the
browsers implemented the accessibility support incorrectly.

Secondly, creating these mapping would test that  that the specification
is not missing any  information / attributes  / requirements  that would
enable sensible meaningful mapping and transfer of information to
different assistive technologies.
If we make mappings based on  complex use cases we will ensure all the
information that is visually implied is also available in the mapping.
There are some cases where we would like to see the mapping as soon as
possible so we can be sure accessibility support is possible. These include:

    * Symbols - cases where  symbols can be mapped directly and where
      they can not;
    * When there is a fallback class - what criteria makes the fallback
      get mapped to the accessibility API as a pose to the original? Is
      there a requirement to specify this;
    * Counter symbol;
    * Pad <integer> && <symbol>.

For the PFWG,
Michael Cooper
PFWG Staff Contact
-- 

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>