Talk:Details element as a replacement for summary attribute, Feb 15, 2010

Feedback on replacing @summary with <details> proposal from Feb 15, 2010

Details element as a replacement for summary attribute, Feb 15, 2010

General

Q: What does this give us that @summary doesn't? (Shelly Powers)

A: The goals of this proposal were to

1. make the summary text more visible to mainstream developers, as many within the WG believe that doing so will improve the quality of summary text.
2. support the same use case as summary, which is text that is hidden from users of visual user agents, but available to users of auditory user agents. That text can be used to describe relationships and patterns in the table data that are obvious looking at the table, but which are difficult to understand when navigating the table cell by cell. On this goal, the intention was to have the same level of support as summary, not more. If this is the goal that one finds important, then this proposal will be identical to keeping @summary.
3. find a compromise position that can achieve consensus.

Q: This seems to be a reversal of previous PF positions. (Laura Carlson)

A: To some extent it does. PF was advocating for keeping the HTML 4 status quo, because it was good enough, and we wanted to spend our energy elsewhere. However, advocating for keeping the same engineering solution from HTML 4 has *not* saved any energy. So, we are now looking to keep the use case, and engineer a new solution that can gain broader working group support.

Q: What are business reasons for considering it unacceptable to have a visible button (Henri Sivonen)

A: There could be many reasons, most of which would not occur to technical people designing a spec, but which can be vitally important to the business of a particular web site. The most common reason would be that it was somehow damaging to the experience or branding of the site. Sometimes advertizing dollars are tied to pixel-perfect placement. While none of us would consider these things to be ideal, they do happen. It is in no-one's interest to set up a situation where business decision makers must choose between accessibiltiy and money.

Why not inside caption?

Q: Allowing details as a child of table causes problems for back-compat. (Henri Sivonen, Lief Halvard Silli)

Q: details as child of table requires changes to table algorithm. OK as child of caption (Henri Sivonen)

Q: Why should authors prefer table or caption as parent (Leif Halvard Silli)

A: The primary reason details is outside cpation was that you might want a hidden summary but not a visible caption. Particularly with the noflow attribute, the details would not require any space on teh page, while caption takes space. There are probably other ways to solve this problem.

Issues around details

Q: This conflicts with outstanding action to create change proposal to remove details (Shelly Powers, Laura Carlson)

A: Yes, it does. I do not support removing details. I mistakenly thought this issue was closed and that details was back in. The biggest flaw in HTML as it exists today is that it is a language which was designed for marking up academic papers, but which is being used to build user interface. It is missing many of the UI elements that are common in desktop operating systems. HTML 5 attempts to address this by adding, for example, <menu>, <input type=range> and <details>. When these elements are supported in mainstream browsers, they will be mapped to appropriate accessiblity APIs on the various platforms, and will have built-in accessibility. In my opinion, the inclusion of these new controls is problaby the most important feature of HTML 5. To that end, I am proposing improving details, by giving in built-in behavior to be a show-on-hover-or-focus expanding area, not just an expanding area. Many such UI elements on existing web sites have that behavior.

Q: Expando UI not usable, more cluttering than details link, annoying to sighted users who click on it (Shelly Powers)

A: If one wants to use a details link, one simply uses <button>Details</button> and styles it appropriately. In some circumstances, the small graphic will be more usuable, in others text will. I'm not opposed to using the text as the default, as long as there is a way to have a browser-default graphic that doesn't have to be supplied by the author, so that details will be instantly recognizable.

Q: Changing summary in details to button reopens issue 83. If we do this, it should be a separate change request. (Maciej Stachowiak)

A: That is unfortunate. I should have been watching this issue. using <summary> will be very confusing because it is the same name as the HTML 4 @summary attribute. It also isn't a good semantic match for the behavior of the expansion trigger, which is a toggle button.

Q: Semantics of button don't match behavior. Button is a form element, default appearance in legacy ATs is wrong. (Henri Sivonen, Shelly Powers) (Lief Halvard Silli disagrees)

A: Interesting. I think it's a very good match. Buttons exist in many places that are not forms. Buttons are a very common UI primitive, used all over applications, such as in toolbars, to open dialogs, etc. Semantically, this is a toggle button.

Q: SHOULD render a small button will "play merry havoc". (Leif Halvard Silli) A: I'm not sure how? Because different browsers will render it differently? I'm fine with MUST, but made it SHOULD to accomodate non-graphical browsers.

Why not CSS?

Q: @noflow as currently defined is a purely presentational attribute. It duplicates functionality that can be achieved with CSS. Some in the HTML WG are opposed to adding new elements or attributes that are purely presentational and do not have any semantic interpretation. (Maciej Stachowiak)

A: Again, interesting. I don't see this as presentational at all, but rather behavioral. Behavior is core to interactive elements, and as such, should be part of their semantics. It is possible to do this in CSS (though the sample didn't work for me). However, it is so much nicer to have a clean semantic for the different behaviors of the detail elements. Presentation vs. Behavior is probably a longer discussion that needs to happen, relating to all the interactive elemetns, including those that can be used in forms.

Q: Leaving this up to CSS styling gives the author much more control over the exact presentation.

A: There's no reason that has to be either-or. What I described was default rendering. It can be overridden with CSS. I'll make that more clear in the text.

Other

Q: What about using a summary child of table, hidden by default, but which author could override with CSS? (Shelly Powers)

A: I'm not opposed to that, though I think reusing the details element is more elegant. I also think the @noflow attribute greatly improves details.

Make the table summary attribute valid and conforming

Make the table summary attribute valid and conforming

Limitations to aria-describedby as replacement for summary or details

The use of color alone to convey information, as utilized in the list of deliverables from the CSS WG, is a point which needs to be highlighted in any discussion of the use of aria-describedby.

On the list of deliverables from the CSS WG, color coding is used to indicate the Style Activity's drafts development status. while there is a legend for the color coding used in the chart, this is the type of info that it is essential to convey to a non-visual or monochrome user explicitly (background and/or foreground values) -- aria-describedby is of limited use here, as the legend simply shows the colors and their associations -- the actual colors (background, in particular) are NOT named and need to be discovered by querying the text in the legend, which is an UNDUE burden on the average user, not to mention cranks like myself...

The legend needs to contain the equivalent information in plain, human parseable language, not as the current legend does, by using examples of background colors but by naming the background colors so that a user can query/command their AT to read text (or process text) that match the specified combinations AND by binding them to their symbolic meaning using SemWeb techniques, such as, for example, RDFa -- a LOT of people forget that even when one separates style from structure, color coding is still a modality-specific means of communicating information, no matter how the color coding is achieved (if a stylesheet falls in the woods...)

This is an important consideration to include in the details element advice on the use of aria-describedby

-- comment by Gregory J. Rosmaita

Internationalization (i18n) Considerations

• summary as an element provides a mechanism for providing multi-lingual information to users based on user preferences/localization; in some jurisdictions, multiple language summaries are required

-- comment by Gregory J. Rosmaita

Steps to Implement PFWG Summary Recommendations

For consideration:

• Steps to Implement PFWG Summary Recommendations

-- comment by Laura Carlson

Summary Element

• For consideration: Long Term Solution Possibility: Summary Element

-- comment by Laura Carlson

The Logical Argument for SUMMARY the Element

• if authors and developers are used to the concept of using the summary attribute for the TABLE element in HTML4, why not simply change summary from an attribute to an element? as an element, summary provides those who have actually used the summary attribute, with capabilities which were not possible when summary was an attribute;
  • one of the internationalization issues authors have faced when using the summary attribute is how to provide multi-lingual versions of information which is limited to an attribute value, without the possibility of programmatically indicating natural language switches, through the use of the lang attribute
• if authors are as ignorant of the HTML4 attribute summary, they won't be confused by an HTML5 element named summary

-- comment by Gregory J. Rosmaita

HTML ISSUE-93 remove the details element

Something to be aware of, consider, and coordinate is HTML ISSUE-93 to remove the details element from HTML5.

Shelley Powers is writing a change proposal for having it removed from the spec.

It would be good to get Shelley's rationale for her proposal and input on the Details element as a replacement for summary attribute proposal as there could be a problem.

-- comment by Laura Carlson

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

Shelley Powers' comments on the proposal

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

Henri Sivonen comments on the proposal