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

The HTML Accessibility Task Force is still discussing this proposal,  
so let's give them relevant feedback but let's also be clear that this  
is not yet a final proposal.

BTW I wanted to add that it's not necessarily the intent to make  
<details> always visible. The proposal as originally written suggested  
a "noflow" attribute which would make <details> invisible except when  
hovered or focused. I pointed out that this could be done with pure  
CSS and made some demoes of how this could work (only tested in WebKit- 
based browsers, may have bugs in others):

http://webkit.org/demos/hover-summary/example1.html
http://webkit.org/demos/hover-summary/example2.html

(I mocked up the <details> element with CSS and JavaScript, this is  
part of what may not work yet in other browsers; if there is interest  
I can attempt to make these demos work better cross-browser. These  
demos are mainly intended to be informative for the Task Force.)

Regards,
Maciej

On Feb 18, 2010, at 5:39 AM, Shelley Powers wrote:

> 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 19:47:38 UTC