W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2012

Re: Feedback: (RE: Finalizing an Issue-204 CP)

From: 'Janina Sajka' <janina@rednote.net>
Date: Thu, 19 Apr 2012 20:47:02 -0400
To: John Foliot <john@foliot.ca>
Cc: "'Cynthia Shelly'" <cyns@microsoft.com>, "'Laura Carlson'" <laura.lee.carlson@gmail.com>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "'Joshue O Connor'" <joshue.oconnor@cfit.ie>, "'Judy Brewer'" <jbrewer@w3.org>, david100@sympatico.ca, "'Richard Schwerdtfeger'" <schwer@us.ibm.com>, "'James Nurthen'" <james.nurthen@oracle.com>, "'Leif Halvard Silli'" <xn--mlform-iua@xn--mlform-iua.no>, "'Jonas Sicking'" <jonas@sicking.cc>
Message-ID: <20120420004702.GT4092@sonata.rednote.net>
John Foliot writes:
> Cynthia Shelly wrote:
> > 5) changed the details section to offer stronger advice to authors not
> > to do this with structured content.
> I continue to advocate for stronger advisory text here. I would propose the following edit/change:
> <p>...However, hidden elements may be used to provide descriptive strings, using aria-describedby and aria-labelledby and the <label> element.</p>
> <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 string content. At the time of this writing, <del>some</del> <ins>most</ins> screen reader products will read both the accessible name and accessible name <ins>with no prompting</ins>, so authors should take care with the length of text provided via this method.</p>
> (Is there a strong reason to not put this final piece in as a <p class="note"> in the spec?)

I believe Laura is also asking for strong author guidance on this. If I
understand a recent email from Laura, she's pretty much on board with
Cynthia's CP if we can get this particular piece strong enough for her
(and you, John).

Now, I've spoken against this today. I'mm willing to cede this point,
even though I have concerns specifically around this point.

So, let me hasten to clarify that I have no problem with strong
guidance. I simply don't want to look at the HTML spec as an authoring
guide, especially as respects ARIA.

I also worry that some of our desire for articulating the warning
several times over, with different words, is a reaction to the profound
way we've been misunderstood on this point over the past year. Well, we
have been profoundly misunderstood, but that's not enough reason to
ratchet up the author guidance level, imo, because we're not changing
spec language to convince those of the WG who have misunderstood, but
the hunderds and thousands of content authors who will look at the spec
over the years to come.

So, I wonder how we'd write this guidance had we not had a year's worth
of misunderstanding? I think there is only one simple message, after
all: "don't expect anything except simple string text to come through."

PS: The part about "keep it appropriate and don't ramble" is, again,
authoring practice. We have concerns about removing and fixing these
issues in Sec. 4.1. We need to take the same approach in Sec. 7.1.

So, with those considerations in mind, what should 7.1 say?



Janina Sajka,	Phone:	+1.443.300.2200

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 Friday, 20 April 2012 00:47:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:28 UTC