Tabletools: add ability to set scope in cell attributes dialog

[Nathalie Sequeira]

Hello,

I was very happy to see how well CKE handles the creation of tables, and its half-automated way of creating table headers, which are essential for table accessibility, esp. for screen readers.

While CKE does a good job in "guessing" the correct directionality of table header scope, it doesn't get them right all the time, and also does not automatically create scope="colgroup" or scope="rowgroup" on merged header cells.

Thus, it would be great if you could add a dropdown to the cell attributes dialog that allows the user to specify the correct scope of a header cell (row|col|rowgroup|colgroup) without having to switch to code view, which is often overwhelming for "mere" content editors.

This dropdown would be perfectly placed following the dropdown with which one can set a cell as data or header cell.

Hoping you can take this option into consideration for the next release, and thanking you in advance!

[Nathalie Sequeira]

Replying to Reinmar: Actually, I was looking for this in version 4.0, but of course, it would be great if it were also included in the v3

Cheers!

[Piotrek Koszuliński]

Version means the first moment when this issue (or lack of feature :P) may be reproduced. This feature was always missing, therefore I set version to 3.0. However, if we going to implement it, it will be added to the latest release only.

[Mike Gifford]

It's either scope/column or header/id. There are some places where one approach is better than the other.

Should this be a v3 issue or should this be fixed first in v4?

Also, I'm not sure if this should be moved to the Accessibility Component. Seems CKEditor folks like to deal with stuff there rather than through the "Accessibility" keyword.

[Jesse Beach]

ChromeVox was recently updated so I retested this issue. Although the problem is still present, I did notice that one button in the group has the label read -- the Source button. I wasn't able to determine what makes this button different. I changed the text in the source to see if the spoken label would reflect the change and it did.

​https://www.evernote.com/shard/s37/sh/7677d5c6-89f3-4c8c-9e6a-519e5eea9b2e/74685d611ffa6b52d3e4eb4bb57ba49d

So somewhere there is a difference between the Source button, which is read correctly, and the other buttons which are not. I thought at first that because the button was the only one in a group, this might affect the reading of the label, but it isn't the case. The Source button is still read when it is part of a group of buttons.

[Nathalie Sequeira]

Replying to mgifford:

It's either scope/column or header/id. There are some places where one approach is better than the other.

Indeed! However, I think it is challenging enough to get content authors to simplify/normalize (e.g., even have headers in place) their table structures wherever possible and check their scope directionality using the simpler scope method.

So while adding the possibility to define attribution via @headers/@id mechanism may be useful as a future development, the likelihood that someone who knows this mechanism can also work in source code anyway for now is IMHO large enough to justify postponing this in favor of leaving @scope as the default automated method, enhanced by the possibility to verify attribution correctness. Simplicity increases the chances of more extensive adoption. ;)

Thanks also to Reinmar for the clarification :)

[Mike Gifford]

I'm all for simplicity. That and doing the accessible thing by default (without asking). If there's a header & the editor can apply accessible tables, it should. It should be an opt-out for non-accessible tables.