W3C home > Mailing lists > Public > public-pfwg@w3.org > January 2014

Re: CSS Counter Styles Level 3 revisted

From: lisa.seeman <lisa.seeman@zoho.com>
Date: Mon, 20 Jan 2014 20:20:16 +0200
To: James Craig <jcraig@apple.com>
Cc: "public-pfwg" <public-pfwg@w3.org>
Message-Id: <143b0e1ab1f.8654521559917560426.-6132445834708192575@zoho.com>
Agreed

All the best

Lisa Seeman

Athena ICT Accessibility Projects 
LinkedIn, Twitter





---- On Mon, 20 Jan 2014 19:47:03 +0200 James Craig&lt;jcraig@apple.com&gt; wrote ---- 


Or better still, a counter block could reference another counter as it’s alt value. 
 
@counter-style box-corner { 
 system: fixed; 
 symbols: ◰ ◳ ◲ ◱; 
 alt: counter(decimal); 
 suffix: ':'; 
} 
 
On Jan 20, 2014, at 9:44 AM, James Craig &lt;jcraig@apple.com&gt; wrote: 
 
&gt; 
&gt; Before this goes out as public WG feedback, I think we should suggest a fix. 
&gt; 
&gt; I think this could possible be covered by extending the CSS4 “alt” property [1]. Current discussion only allowed its use on pseudo elements. E.g. 
&gt; 
&gt; li::before { 
&gt; content: counter(box-corner); 
&gt; alt: counter(numbered); 
&gt; } 
&gt; 
&gt; But the CSS ‘alt’ property could possibly be extended to be part of the counter declaration so that each use of the counter style would get it by default: 
&gt; 
&gt; @counter-style box-corner { 
&gt; system: fixed; 
&gt; symbols: ◰ ◳ ◲ ◱; 
&gt; alt: '1' '2' '3' '4'; 
&gt; suffix: ':'; 
&gt; } 
&gt; 
&gt; [1] Alt in CSS4 on generated content pseudo elements: 
&gt; http://lists.w3.org/Archives/Public/www-style/2012Nov/0318.html 
&gt; 
&gt; On Jan 14, 2014, at 10:54 AM, lisa.seeman &lt;lisa.seeman@zoho.com&gt; wrote: 
&gt; 
&gt;&gt; Hi. 
&gt;&gt; I was asked to explain the comments made on CSS Counter Styles Level 3 (see http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130718/) 
&gt;&gt; 
&gt;&gt; I have given some clarifications/ examples here on the two issues we raised. The original email and responce is bellow the clarifications. Anything in quotes is copied directly from the specification. 
&gt;&gt; 
&gt;&gt; And now to the main: We had two comments: 
&gt;&gt; 
&gt;&gt; Comment 1 was to support accessible usage 
&gt;&gt; To support accessible usage we suggested: 
&gt;&gt; 1.1. It should be a requirement that accessible content alternative is provided (when content is inaccessible) and 
&gt;&gt; 1.2 All examples in the specification should support accessibility. 
&gt;&gt; 
&gt;&gt; To clarify this with examples from the specification: 
&gt;&gt; The counter style can change the meaning - for example " a negative sign, which is prepended or appended to the representation of a negative counter value. " 
&gt;&gt; The style can give information that is not machine understandable for example " cyclic counter styles just cycle through their symbols" 
&gt;&gt; These styles can have meaning (such as a tick for a correct example and a cross for a false example) 
&gt;&gt; 
&gt;&gt; The specification supports a spoken form ("speak-as"), which describes how to read out the counter style in a speech synthesizer. However the examples of symbols in the specification did not use a speak-as alternatives, and speak-as is not required when symbols or counter style convay invformation 
&gt;&gt; 
&gt;&gt; 
&gt;&gt; Example from the specification 
&gt;&gt; " 
&gt;&gt; @counter-style box-corner { system: fixed; symbols: ◰ ◳ ◲ ◱; suffix: ':';} 
&gt;&gt; 
&gt;&gt; 
&gt;&gt; Comment 2: Accessibility API mapping 
&gt;&gt; We requested information for how user agents, such as a browser should should map this specification to the accessibility API. 
&gt;&gt; 
&gt;&gt; It needs to be specified especially as a "speak-as" option is not a requirement, so we can not rely on that. 
&gt;&gt; 
&gt;&gt; for example: WHat cshould be mapped when there is a fall back counter style and no "speek-as" option ? 
&gt;&gt; what about when the "speak-as" option is out of range. 
&gt;&gt; 
&gt;&gt; Should APIs map to the fall back value all the time if there is no "speak-as"? 
&gt;&gt; 
&gt;&gt; Note: "If the value of the fallback descriptor isn't the name of any currently-defined counter style, the used value of the fallback descriptor    is decimal instead. " 
&gt;&gt; 
&gt;&gt; Looking at two example from the speck: 
&gt;&gt; "@counter-style decimal-leading-zero { system: fixed -9; symbols: '-09' '-08' '-07' '-06' '-05' '-04' '-03' '-02' '-01' '00' '01' '02' '03' '04' '05' '06' '07' '08' '09';}" 
&gt;&gt; and 
&gt;&gt; "@counter-style cjk-decimal { system: numeric; symbols: \3007 \4E00 \4E8C \4E09 \56DB \4E94 \516D \4E03 \516B \4E5D; /* 〇 一 二 三 四 五 六 七 八 九 */ suffix: '\3001'; /* "、" */}" 
&gt;&gt; 
&gt;&gt; Note that for both examples 
&gt;&gt;     • no "speak-as" is provided 
&gt;&gt;     • the default fallback is decimal 
&gt;&gt; 
&gt;&gt; For each example - what should be mapped to the accessibility API ? How should the browser work that out? 
&gt;&gt; I would guese that the decimal default works well for the second example, and not at all for the first example. But how does the browser know that? 
&gt;&gt; 
&gt;&gt; All the best 
&gt;&gt; Lisa 
&gt;&gt; 
&gt;&gt; should 
&gt;&gt; in an interoperable manner. This&gt; means that different browsers will do it differently and often incorrectly.&gt; Hence, the author will not be able to make accessible content.&gt; 
&gt;&gt; 
&gt;&gt; 
&gt;&gt; 
&gt;&gt;&gt;&gt; Comment 1: Support accessible usages&gt;&gt; In general we think it is possible to make accessible content using this&gt; specification. However, we feel that it will not be clear to users how to&gt; make accessible content, and a lot of content that conforms to this&gt; specification may not be accessible. We propose that:&gt;&gt; It should be a requirement that accessible content alternative is provided&gt; (when content is inaccessible);&gt; All examples in the specification should support accessibility.&gt;&gt; For example, it may be be possible, by having a fallback class with the&gt; "speakas" option, to create what is essentially alt text for symbols. In&gt; cases like this - where symbols represent true information - a text&gt; equivalent fallback class should be not just possible but a requirement. If&gt; it is considered inappropriate to require this we would at least like it to&gt; 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 onlyusable to format list item bullets (via the list-style-type property)and CSS counters (via the counter() and counters() functions). Inparticular, it's not usable, except perhaps in an extremely hacky androundabout fashion, as a way to produce symbols in text, like "symbolfonts" are used for.It's far easier to produce symbols in the proper, accessible way. 
&gt;&gt; 
&gt;&gt; 
&gt;&gt; 
&gt;&gt; 
&gt;&gt; 
&gt;&gt; 
&gt;&gt; 
&gt;&gt;&gt; Comment 2: Accessibility API mapping&gt;&gt; It is not clear how user agents (assistive technology and browsers) should&gt; support this specification to provide consistent accessibility support. Many&gt; assistive technology's (AT) work via an accessibility API (AAPI), where the&gt; browser populates a custom data structure in the AAPI and the AT present&gt; that information in the way best suited to the user's needs. More&gt; information on this topic can be found at&gt; http://www.w3.org/TR/wai-aria-roadmap/.&gt;&gt; At present there is not information for how user agents should should map&gt; CSS features cases to the accessibility API in an interoperable manner. This&gt; means that different browsers will do it differently and often incorrectly.&gt; Hence, the author will not be able to make accessible content.&gt;&gt; We would like specification to specify the mapping of these attributes and&gt; classes to the user agent and accessibility API of the operating system.&gt; This will enable user agents to know how to correctly support the&gt; specification, which would make it much more likely that accessibility will&gt; not just be theoretically supported, but to be actually and correctly&gt; supported by user agents. We are happy to work with you on how to do these&gt; mappings.&gt;&gt; There are two other advantages to doing this. Firstly it will also give us a&gt; clear way to determine if and when user agent support is sufficient to&gt; allow authors to use this specification. FYI, as many large sites are&gt; required to provide accessible content, and then accessibility support for&gt; real users is a legal requirement. In such cases authers will not be alowecd&gt; to adopt this specification becuse the browsers implemented the&gt; accessibility support incorrectly.&gt;&gt; Secondly, creating these mapping would test that that the specification is&gt; not missing any information / attributes / requirements that would enable&gt; sensible meaningful mapping and transfer of information to different&gt; assistive technologies.&gt; If we make mappings based on complex use cases we will ensure all the&gt; information that is visually implied is also available in the mapping.&gt; There are some cases where we would like to see the mapping as soon as&gt; possible so we can be sure accessibility support is possible. These include:&gt;&gt; Symbols - cases where symbols can be mapped directly and where they can&gt; not;&gt; When there is a fallback class - what criteria makes the fallback get mapped&gt; to the accessibility API as a pose to the original? Is there a requirement&gt; to specify this;&gt; Counter symbol;&gt; Pad &lt;integer&gt; &amp;&amp; &lt;symbol&gt;.I believe that 'speak-as' correctly describes the accessibilitymapping. If it doesn't, can you describe what is missing? I'm notfamiliar with the accessibility APIs directly, but so far as Iunderstand, indicating that a list is bulleted or numbered isstandard, and I suspect that lists "numbered" with letters are alsopossible to express in the APIs, so as to properly indicate nestedlists. That's the totality of what 'speak-as' can do, so I'm not surewhat else needs to be specified. 
&gt;&gt; 
&gt;&gt; All the best 
&gt;&gt; 
&gt;&gt; Lisa Seeman 
&gt;&gt; 
&gt;&gt; Athena ICT Accessibility Projects 
&gt;&gt; LinkedIn, Twitter 
&gt;&gt; 
&gt;&gt; 
&gt;&gt; 
&gt; 
&gt; 
 
Received on Monday, 20 January 2014 18:22:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:44:59 UTC