RE: [css3-speech] ISSUE-153 speak: none; usage incompatible with other values of speak

Daniel Weck [mailto:daniel.weck@gmail.com] wrote on Wednesday, January
19, 2011 8:09 AM
> 
> Oops, I apologize for this editorial mistake: I meant 
> "display:none", not "visibility:hidden". The former 
> effectively 'deactivates' an element (so to speak) whereas 
> the latter is more similar to "voice- volume:0%". In other 
> words, "visibility:hidden" preserves the visual space that 
> the element would normally occupy if it was visible 
> (resulting in an empty or transparent area that still takes 
> part in the page layout), and conversely "voice-volume:0%" 
> results in an audio silence lasting as long as the duration 
> of non-silent TTS playback.  
> Regards, Daniel

Actually, that's an argument in favor of speak:none.  It would be
inconvenient to make listeners wait for something that is merely hidden
to sighted readers.

Hope this helps,
Charles Belov
SFMTA Webmaster

> 
> On 19 Jan 2011, at 14:54, Daniel Weck wrote:
> 
> > Hi Charles,
> > personally I see no valid use-case for wanting to "hide" 
> text in the 
> > aural dimension, whilst making it visible on the graphical canvas.
> > More importantly, I'm pretty sure that this behavior violates 
> > accessibility good practices.
> >
> > After having looked at several authoring scenarios, I 
> remain convinced 
> > that "speak:none" should  be removed from the current 
> draft, and that 
> > instead "visibility:hidden" should be used to control element 
> > "deactivation". I believe the role of the "speak"
> > property should be limited to controlling the _style_ in which 
> > elements get spoken out.
> >
> > Any other thoughts ?
> > Regards, Daniel
> >
> > On 12 Jan 2011, at 21:43, Belov, Charles wrote:
> >
> >> fantasai.lists@inkedblade.net wrote on Wednesday, January 12, 2011
> >> 10:53
> >> AM
> >>> CSS-ISSUE-153
> >>>
> >>> http://www.w3.org/Style/CSS/Tracker/issues/153
> >>>
> >>> The 'speak' property has two functions: one is to dual as 
> the speech 
> >>> equivalent of 'visibility', the other is to specify how 
> to speak the 
> >>> contents of an element.
> >>>
> >>> This creates unintentional problems with, e.g.
> >>>
> >>> acronym {
> >>> speak: spell-out;
> >>> }
> >>>
> >>> p.hide {
> >>> speak: none;
> >>> }
> >>>
> >>> <p>Thing to hide <acronym>WOAH</acronym> more stuff to hide</p>
> >>>
> >>> The WOAH is suddenly injected into the speech rendering 
> due to the 
> >>> acronym rule, even though that is probably not what's intended.
> >>> These functions should be separated into two properties, or the 
> >>> 'none' value removed entirely.
> >>>
> >>
> >> I do find the wording for none odd:
> >>
> >> Suppresses aural rendering so that the element requires no time to 
> >> render. Note, however, that descendants may override this 
> value and 
> >> will be spoken. (To be sure to suppress rendering of an 
> element and 
> >> its descendants, use the 'display' property
> >>
> >> What if you only want to suppress the sound and not the display 
> >> (although I'd want to see a use case that did not violate 
> >> accessibility standards)?
> >>
> >> In any case, I believe one could code:
> >>
> >> acronym {
> >> speak: spell-out;
> >> }
> >>
> >> p.hide {
> >> speak: none !important;
> >> }
> >>
> >> or perhaps
> >>
> >> acronym {
> >> speak: spell-out;
> >> }
> >>
> >> p.hide,
> >> p.hide * {
> >> speak: none;
> >> }
> >>
> >> Whether that is sufficient to alleviate concerns is another issue.
> >>
> >> Hope this helps,
> >> Charles Belov
> >> SFMTA Webmaster
> >>
> >>
> >
> > Daniel Weck
> > daniel.weck@gmail.com
> >
> >
> >
> 
> Daniel Weck
> daniel.weck@gmail.com
> 
> 
> 
>

Received on Friday, 21 January 2011 18:52:33 UTC