Re: Finalizing an Issue-204 CP

Cynthia Shelly writes:
> 1) I like this text, and have added it.


+1


> 2) This one is trickier... If the spec says that hidden elements must be hidden from all presentations, then the browser devs will do that.  IE has done that with @hidden, so that it does not populate the accessibility API, even with flattened string content, where it does populate it with display:none and the other examples in the CP.  I think the right approach is something like
> 
> Browsers (SHOULD NOT) create accessibile objects in the accessibility API tree.  Browsers (MAY | SHOULD) flatten the text children to create a plain-text string to fill in the name and description properties of the referring object.
> 
Unfortunately, that makes it sound as though there's a choice to have
flat string, or semantic rich. We need to keep clarity that the APIs
constrain what we can, and cannot do.

Janina

> Authors (MUST NOT | SHOULD NOT) reference hidden elements with complex structure from non-hidden elements.
> 
> Your text from #1 covers the authors requirement. 
> For the browsers requirement, I have added the following to the first paragraph of the proposed hidden attribute section, in the CP details
> User agents should not create accessible objects in the platform accessibility API tree for elements that have the hidden attribute specified. User agents may use the text-children of the hidden element to create a plain-text string, and use that string to fill in name and description properties in the objects created for the referring element, which does not have the hidden attribute specified. See the HTML to Platform Accessibility APIs Implementation Guide for more details.
> 
> I'll be cleaning up markup and making the rest of Laura's changes shortly.  I hope this addresses your concern.
> 
> -----Original Message-----
> From: Benjamin Hawkes-Lewis [mailto:bhawkeslewis@googlemail.com] 
> Sent: Tuesday, April 24, 2012 12:00 PM
> To: Cynthia Shelly
> Cc: Laura Carlson; 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)
> Subject: Re: Finalizing an Issue-204 CP
> 
> On Tue, Apr 24, 2012 at 12:40 AM, Cynthia Shelly <cyns@microsoft.com> wrote:
> > 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.
> 
> It's better to drop contentious requirements than paper over disagreements by watering them down. It's even better to hone the requirements until they command consensus.
> 
> This is why I suggested focusing the conformance requirement on the generated plain text not the source markup.
> 
> For example you could use text like:
> 
> "Note hidden labels and descriptions will not be exposed as objects in the accessibility tree, but may be used as part of accessible name and description calculation [WAI-ARIA]. Note the calculation will flatten the labelling and describing elements to plain text strings, losing interactivity and semantic structure. Authors must only use hidden labels and descriptions to label and describe elements when the calculated plain text strings are appropriate accessible names or descriptions."
> 
> For example the following would conform to this particular requirement because although <label> includes a sub-element, it still flattens to an appropriate accessible name for the <input>.
> 
>    <input id=f type=checkbox checked>
>    <label hidden for=f>
>      I do <strong>not</strong> want to receive marketing materials.
>    </label>
> 
> > 2) 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.
> 
> We should encourage people to add accessibility text in ways that make it robustly available to anyone who needs it. That's only an intersecting set with the set of people who are using accessibility API clients.
> 
> We often expose accessibility text to the APIs without making it conforming markup.
> 
> Consider <img> with @title but no @alt. ARIA maps this so that @title provides an accessible name for <img>. But by recent WG decision, it's also non-conforming because @title has usability problems.
> 
> Similarly, hiding labels and descriptions with @hidden has demonstrable usability problems.
> 
> Consider the case of users rejecting author styles in favour of styles that make content/services more accessible to them. Merely rejecting author styles will not make @hidden labels and descriptions visible, but it will make labels and descriptions hidden with CSS visible.
> 
> Even if we allow that there are cases where hiding labels didn't have demonstrable usability problems, we already have a markup feature that works really well for this purpose: @aria-label. Since it's less likely to break, we should encourage its use over more brittle techniques. You say it's "sometime a better technique", but this seems questionable given nobody's come forward with an example where it would be better.
> 
> As for descriptions, assuming you already have an accessible name, what sort of additional short description would you not want rendered
> *even* when your images are not displayed and your CSS is not applied?
> 
> There's a broader problem here where the spec is walking away from requiring authors to provide names for controls or even providing them good advice on how to provide such names. The text for @hidden seems to be the wrong place to fix this though.
> 
> Compare: https://www.w3.org/Bugs/Public/show_bug.cgi?id=10710
> 
> --
> Benjamin Hawkes-Lewis
> 
> 

-- 

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 21:48:13 UTC