Re: Finalizing an Issue-204 CP

Thanks, Cynthia. It's very helpful to see this consensus emerge in a CP where
such a wide range of previously expressed concerns and concepts is also addressed.

Janina

Cynthia Shelly writes:
> I won't be able to make any updates to the CP until tomorrow mid-morning Pacific time, but wanted to respond to these points for your text subteam discussion.  I have no problem making any of these changes.  On #1, I prefer should, but I can live with stronger text.
> 
> 1) I prefer should, and the " where such flattened content will provide a good user experience" text, because I think there are times when flattening small amounts of markup in a short label doesn't cause a problem.  However, I can live with must not, and the rest of the stronger language here.  There may be others who object, so I was trying to make it softer.  
> 
> 2) Messy fast typing.  I will fix the errors in the markup.  I also agree that using aria-label is sometime a better technique, but I would like to see the widest range of techniques for providing accessibility text work.  If someone has tried to add accessibility text, I want it in the APIs.  
> 
> 3) Editorial.  Ok.  That came from Jonas' proposal.  I don't mind changing it, just wanted to keep as much of that proposal as possible.
> 
> 4) no problem.
> 
> -----Original Message-----
> From: Laura Carlson [mailto:laura.lee.carlson@gmail.com] 
> Sent: Monday, April 23, 2012 10:10 AM
> To: Cynthia Shelly
> Cc: Janina Sajka; HTML Accessibility Task Force; John Foliot; Joshue O Connor; Judy Brewer; david100@sympatico.ca; Richard Schwerdtfeger; James Nurthen; Leif Halvard Silli; Jonas Sicking (jonas@sicking.cc); Benjamin Hawkes-Lewis
> Subject: Re: Finalizing an Issue-204 CP
> 
> Hi Cynthia and everyone,
> 
> > http://www.w3.org/html/wg/wiki/Correct_Hidden_Attribute_Section_v2#Acc
> > essibility_API_mappings
> >
> > 1) rewrote summary to talk more about @hidden being simpler than CSS, 
> > rather than @aria-describedby being simpler than something else
> > 2) changed example to one using an input and a label rather than an 
> > image with a short and long description
> > 3) added section on what happens in the API when the item is hidden or 
> > not hidden
> > 4) added the aria-labelledby row to the table from UIAG to show that 
> > the behavior is not just for description
> > 5) changed the details section to offer stronger advice to authors not to do this with structured content.
> > 6) minor copy edits, adding <code> styling, etc.
> 
> Wow. Big improvements. Thank you Cynthia for your work. This is really coming along. I have the following suggestions. With these few changes, I see no reason not to withdraw my proposal in favor of yours.
> 
> 1. Change:
> <p class="note">Any structure in the referenced element, including headings, links, tables, paragraphs, and form elements, will be lost.
> The text children of the element will be flattened to a string. As such, authors should only use this technique for where such flattened content will provide a good user experience. At the time of this writing, some screen reader products will read both the accessible name and accessible description, so authors should take care with the length of text provided via this method.</p>
> 
> To something like:
> 
> "This technique must not be used for longer content that has structured text as accessible name and description calculation [WAI-ARIA] will flatten the referenced elements to plain text, losing interactivity and semantic structure.
> <p class="note">Additionally at the time of this writing, some screen reader products will read both the accessible name and accessible description, so authors should take care with the length of text provided via this method.</p>"
> 
> Although your current version is a big improvement over and does offer stronger advice to authors to not use the technique with structured content than your previous versions, Benjamin's April 21 message provides strong rationale for having this part of the spec text be normative (last few paragraphs of:
> http://lists.w3.org/Archives/Public/public-html-a11y/2012Apr/0166.html )
> 
> By the way, this new suggested spec text is a variation of what I have/had in my CP. The main difference is I have/had it as a "should not". But I can't think of a reason to not make it a "must not". If someone can provide rationale for "should not", "should not" is okay with me.) http://www.w3.org/html/wg/wiki/index.php?title=ChangeProposals/CorrectHidden&oldid=12763#warning
> 
> 2. I would suggest reviewing and possibly deleting the problematic examples that Benjamin identified.
> 
> 3. Change:
> "The @hidden attribute is the simplest, most straightforward mechanism for hiding elements in HTML or CSS."
> 
> To something like:
> "The @hidden attribute is a mechanism for hiding elements in HTML."
> 
> Rationale:
> * The phrase: "simplest, most straightforward" is opinion and circumstantial. It may be true for some authors under some situations.
> In others it may not be.
> * The @hidden attribute doesn't hide elements in CSS. It hides things in HTML.
> 
> 4. Change:
> 
> All instances of the word "string" to the words "plain string text" or "plain text".
> 
> Rationale see Benjamin's April 21 message:
> http://lists.w3.org/Archives/Public/public-html-a11y/2012Apr/0166.html
> 
> Again, thanks Cynthia. I really appreciate all of your work on this.
> Thanks to you too Benjamin for your keen observations.
> 
> Best Regards,
> Laura
> --
> Laura L. Carlson
> 
> 

-- 

Janina Sajka,	Phone:	+1.443.300.2200
		sip:janina@asterisk.rednote.net

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)

Received on Tuesday, 24 April 2012 00:59:19 UTC