Re: Feedback on using <details> as a replacement of summary="..."

Henri Sivonen wrote:
> (Previously sent to public-html-a11y@w3.org, but that address refused my message. This message has been edited slightly for clarity.)
>
> In reference to:
> http://www.w3.org/WAI/PF/HTML/wiki/Details_element_as_a_replacement_for_summary_attribute%2C_Feb_15%2C_2010
>
>   
>> 	• Allow details as a child of table or caption
>>     
>
>   

I just found out about this recent change proposal. I have an upcoming 
change proposal providing an argument to delete details from the 
specification, altogether. My proposal is due March 31st, I believe. 

Regardless of whether it was removed or not, this is an option I 
wouldn't support. No one has provided what I feel is a convincing 
argument for replacing the summary attribute. The summary attribute had 
a specific purpose for a specific audience -- that hasn't changed 
between HTML4 and now. The purpose still exists, the audience still exists.

Providing a "visible" option, because the assumption is that the only 
reason summary isn't being used correctly is because it isn't "seen" by 
sighted users is ignoring the elephant in the corner: the most likely 
reason summary wasn't used correctly is that a lot of web page designers 
just didn't care. And you can't use technology to try to fix a bad attitude.

If anything, having this little button/triangle thing in the table, with 
a label, visible to everyone, asking to be clicked, only to display 
information that the people don't need, or most likely want, doesn't 
make a lot of sense to me. According to the rationale, one of the 
purpose for this change is:

"Providing information about the content and structure of a table to 
users who cannot see the table, including some information that will be 
obvious to users who can see the table, and which might be cause the 
user interface to become cluttered and less usable for users who can see 
the table."

I just can't think of anything more cluttering than a button/triangle 
with label in a table that I shouldn't push. I notice, though, that 
another aspect of the proposal is that details not be visible by default 
in the table? But the whole concept of the element is that by default 
the label part should be visible. This is going to play all sorts of 
havoc with the web authoring community.

I do agree in the proposal that there is confusion about the use of 
summary, for an element of details, as compared to summary as table 
attribute. However, I was the only person who raised an objection on 
this name. I would not have removed my own objection if I had seen 
support for this objection from other members of the HTML WG team.

Is this Accessibility Task Force's official recommendation as change 
proposal? Are there other change proposals, such as keeping summary? I 
notice this is being actively edited -- is this just one of other change 
proposals?

> Allowing <details> as a child of <caption> is fine. Allowing it as a child of <table> is not acceptable due to ungraceful degradation behavior. You can't introduce new children of <table> without ill effects in existing UAs.
>
> Note that the "Spec Changes" part of the wiki page fails to include a change to the parsing algorithm for making it possible to use <details> as a child of <table> in the text/html serialization. (I'd be opposed to changing the parsing algorithm on this point, though.)
>
>   
>> 	• Replace the summary child element of details with a button.
>>     
>
> This seems like a bad idea to me, because <button> has pre-existing behavior that isn't designed for making <button> act as a disclosure triangle and the disclosure triangle label.
>
>   

Agree with Henri -- regardless of whether details is kept or not, using 
a button to replace the label text and triangle is against all 
established uses for this type of "expando" or "accordion" behavior.  
And will cause confusion about uses of button, as a button.
> P.S. What are "business reasons" for considering it unacceptable to have a visible description?
>
>   
Shelley

Received on Thursday, 18 February 2010 13:39:41 UTC