Re: CSS Counter Styles Level 3 revisted

That is a realy good and important point. I think we should add it to our response. 

The CSS WG response suggests that they consider accessibility to be supported because of the speak-as, and we need to tell them that that is not full support.

All the best

Lisa Seeman

Athena ICT Accessibility Projects 
LinkedIn, Twitter





---- On Tue, 21 Jan 2014 01:04:58 +0200 James Craig<jcraig@apple.com> wrote ---- 


Speak-as is not the same as alternative text. It just allows you to specify whether strings should be spoken with or without punctuation, whether numbers should be spoken as numbers (thirteen) versus digits (one three), whether to spell out or pronounce acronym, etc. 


In addition, my understanding is that the entirety of the CSS Speech Module (including speak-as) seems to be very focused on spoken books, and does not apply in many cases to other assistive technologies like screen readers. I previously voiced this concern on that list and none of my feedback was incorporated. It’s being driven by Daisy, which explains their focus on books, but not their unwillingness to incorporate changes that would make CSS 3 Speech work better for other assistive technology uses.



On Jan 20, 2014, at 10:22 AM, lisa.seeman <lisa.seeman@zoho.com> wrote:

They do have a "speak-as" option which is a similar thing.

All the best

Lisa Seeman

Athena ICT Accessibility Projects
LinkedIn, Twitter





---- On Mon, 20 Jan 2014 19:44:40 +0200 James Craig<jcraig@apple.com> wrote ---- 



Before this goes out as public WG feedback, I think we should suggest a fix. 
 
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. 
 
li::before { 
 content: counter(box-corner); 
 alt: counter(numbered); 
} 
 
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: 
 
@counter-style box-corner { 
 system: fixed; 
 symbols: ◰ ◳ ◲ ◱; 
 alt: '1' '2' '3' '4'; 
 suffix: ':'; 
} 
 
[1] Alt in CSS4 on generated content pseudo elements: 
http://lists.w3.org/Archives/Public/www-style/2012Nov/0318.html 
 
On Jan 14, 2014, at 10:54 AM, lisa.seeman <lisa.seeman@zoho.com> wrote: 
 
> Hi. 
> 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/) 
> 
> 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. 
> 
> And now to the main: We had two comments: 
> 
> Comment 1 was to support accessible usage 
> To support accessible usage we suggested: 
> 1.1. It should be a requirement that accessible content alternative is provided (when content is inaccessible) and 
> 1.2 All examples in the specification should support accessibility. 
> 
> To clarify this with examples from the specification: 
> 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. " 
> The style can give information that is not machine understandable for example " cyclic counter styles just cycle through their symbols" 
> These styles can have meaning (such as a tick for a correct example and a cross for a false example) 
> 
> 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 
> 
> 
> Example from the specification 
> " 
> @counter-style box-corner { system: fixed; symbols: ◰ ◳ ◲ ◱; suffix: ':';} 
> 
> 
> Comment 2: Accessibility API mapping 
> We requested information for how user agents, such as a browser should should map this specification to the accessibility API. 
> 
> It needs to be specified especially as a "speak-as" option is not a requirement, so we can not rely on that. 
> 
> for example: WHat cshould be mapped when there is a fall back counter style and no "speek-as" option ? 
> what about when the "speak-as" option is out of range. 
> 
> Should APIs map to the fall back value all the time if there is no "speak-as"? 
> 
> 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. " 
> 
> Looking at two example from the speck: 
> "@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';}" 
> and 
> "@counter-style cjk-decimal { system: numeric; symbols: \3007 \4E00 \4E8C \4E09 \56DB \4E94 \516D \4E03 \516B \4E5D; /* 〇 一 二 三 四 五 六 七 八 九 */ suffix: '\3001'; /* "、" */}" 
> 
> Note that for both examples 
>     • no "speak-as" is provided 
>     • the default fallback is decimal 
> 
> For each example - what should be mapped to the accessibility API ? How should the browser work that out? 
> 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? 
> 
> All the best 
> Lisa 
> 
> should 
> 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.> 
> 
> 
> 
> >> 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 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. 
> 
> 
> 
> 
> 
> 
> 
> > 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 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. 
> 
> All the best 
> 
> Lisa Seeman 
> 
> Athena ICT Accessibility Projects 
> LinkedIn, Twitter 
> 
> 
>