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

On Wed, Aug 21, 2013 at 11:46 AM, Michael Cooper <cooper@w3.org> wrote:
> 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.

I don't fully understand this feedback.  The counter styles defined by
@counter-style cannot be used to format arbitrary text; they're only
usable to format list item bullets (via the list-style-type property)
and CSS counters (via the counter() and counters() functions).  In
particular, it's not usable, except perhaps in an extremely hacky and
roundabout fashion, as a way to produce symbols in text, like "symbol
fonts" are used for.

It's far easier to produce symbols in the proper, accessible way.

> 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/.
>
> 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>.

I believe that 'speak-as' correctly describes the accessibility
mapping.  If it doesn't, can you describe what is missing?  I'm not
familiar with the accessibility APIs directly, but so far as I
understand, indicating that a list is bulleted or numbered is
standard, and I suspect that lists "numbered" with letters are also
possible to express in the APIs, so as to properly indicate nested
lists.  That's the totality of what 'speak-as' can do, so I'm not sure
what else needs to be specified.

~TJ

Received on Friday, 1 November 2013 23:49:27 UTC