redraft ..... Suggestions for CSS Counter Styles

Review of CSS Counter Styles Level 3 (see http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130718/ )

We would like to raise two points/issues:

Issue 1: For most if it we feel that it is possible to make accessible content using this specification. However, we feel that it will not be clear to users  clear how to use this specification to make accessible content, and a lot of content that conforms to this specification will not be accessible. We would like to see inside the specification:
    It should be a requirement that accessible content alternative is provided (when content is inaccessible) and
    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.

Issue 2. We are concerned that 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 accessible API , where the browser writes the information to populate the DOM tree in the accessible API 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/

     We think browsers will be  confused as to  how to should map to a lot of your use cases to the accessibility API. (Actually we were confused too) 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 CSS 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. In other words this 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 give guidance 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 usecase we will insure 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. They are use case using:

        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 symbols
        Pad <integer> && <symbol> 



    All the best
    Lisa Seeman