Opened 10 years ago

Last modified 10 years ago

#12238 confirmed Bug

Do not use the table summary attribute

Reported by: Mike Gifford Owned by:
Priority: Normal Milestone:
Component: Accessibility Version: 3.0
Keywords: Cc:

Description

We ran into this with Drupal 8 - https://www.drupal.org/node/843708

There are a great list of examples - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/table#attr-summary

But using:

<table summary="descriptive text">

No longer fits with the HTML5 specs.

Using details/summary works fine: http://www.developerfusion.com/article/136530/making-tables-more-accessible-with-html5/ http://www.pdprogrammeur.com/tables-and-html5-table/

The UI shouldn't need to change, just the placement of the summary text.

Change History (6)

comment:1 Changed 10 years ago by Piotrek Koszuliński

Keywords: atag accessibility removed
Status: newpending
Version: 4.4.33.0

Tricky situation. CKEditor will still need to handle the summary attribute, because previously created HTML may be loaded into it. It also should not move the attribute to the caption>details (if that's what we'll choose) automatically, because we must avoid changing loaded data. Additionally, summary is now an invisible data, while caption>details>summary is by default visible. Actually, I'm worried that we would need to use widget to keep the summary element safe and in such case a patch would have to be implemented in a separate plugin.

I think that we may also consider removing the summary input from the dialog. Since table may also have caption, is summary necessary? How does it look from a11y's POV?

comment:2 Changed 10 years ago by Mike Gifford

Yes, sadly, both are still required for accessibility. They fill different functions.

Managing legacy content is always difficult.

Caption should be visible, but the summary is important for providing other context to the AT user.

comment:3 Changed 10 years ago by Jakub Ś

Status: pendingconfirmed

Both are still required so perhaps they can be set based on doctpye and existing code?

Anyway I'm confirming this issue as it sems valid

comment:4 Changed 10 years ago by Mike Gifford

Nice idea leveraging the doctype....

But still if someone has an old table in an HTML5 site that they put in place with today's CKEditor, they upgrade to the latest version six months from now and there will have to be some conversion between the old HTML4 style to the current HTML5 style.

The content fields with Captions & Summaries can still be the same from the UI perspective. They just need to be executed using Details/summary elements and carefully hidden from view.

comment:5 Changed 10 years ago by Jakub Ś

Nice idea leveraging the doctype....

Doctype can be tricky because CKEditor 4 uses HTML5 doctype by default. Because of that there shouldn't definitely be any automatic conversion. If someone by mistake use old tables in new editor and then saved them we would have his HTML4 unwillingly updated (destroyed).

That is why just not touching the code and perhaps loading correct fields to table dialog based on code could be a solution here?

and there will have to be some conversion between the old HTML4 style to the current HTML5 style

That is correct. If there are users that want to switch then perhaps table dialog could have some button "upgrade/downgrade summary to HTML5/HTML4" that changes code and reloads correct filed in dialog.

I'm not sure though if this isn't too much for such a simple feature. Hopefully @fredck or @Reinmar will have better ideas.

comment:6 Changed 10 years ago by Piotrek Koszuliński

CKEditor is configured to use HTML5's Doctype by default, so we cannot base on that. I'm rather thinking about a separate plugin (e.g. "tablesummary" or something more meaningful like "tablehtml5summary"). This plugin would move summary attributes to captions, so it would be developer's choice whether (s)he wants attributes or HMTL5's structure.

I think that in design mode (inside editor) the summary should not be visible or at least editable, because it will be hard to make proper constraints, so user won't destroy the structure. The summary text will be editable through the table dialog, just like now. Alternatively, it could be a widget with nested editable... what's an option too, but it's definitely more complicated.

Another thing that worries me are translations. In ​http://www.developerfusion.com/article/136530/making-tables-more-accessible-with-html5/ this is proposed:

<caption>
  <strong>Characteristics with positive and negative sides.</strong>
  <details>
   <summary>Help</summary>
   <p>Characteristics are given in the second column, with the
   negative side in the left column and the positive side in the right
   column.</p>
  </details>
 </caption>

So the "Characteristics..." part is a summary editable in the dialog or as nested widget. And what about "Help"? Should it be editable (is it related to context or can always be "Help"? Can we simplify simplify this HTML structure somehow?

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy