Best practices for table display and markup

RachelComerford commented 6 years ago

From BISG survey

JayPanoz commented 6 years ago

a11y:

Pretty sure there are more (and more recent) though.

Responsive:

Not holding my breath there, as this is a problem on the web as well and there’s no perfect solution (in addition, 95% of those techniques don’t work in a paginated ebook environment).

Complex tables e.g. multiple table headers with `colspan`, lots of columns/rows:

I had to manage that 18 months ago and unless you’re using JavaScript, good luck with that…

RachelComerford commented 6 years ago

@jcalderazi is this one you think you could kick off documentation for?

As you explore this topic - please keep this guiding structure in mind:

identify quirks or exceptions in specific reading systems (edited)
Identify gaps in documentation that need to be developed
Identify variations based of business verticals - how might you implement this standard differently as journal publisher vs a textbook publisher? A magazine vs scholarly? etc.
Use plain language. Use diagrams where they will help (and provide alt text). Tag your colleagues for assistance.
If you reference prior art, older development projects, or other materials, provide clarifying information including a basic definition and the importance to the best practice

When you are proposing language/contributions to best practice, please consider and respond to the following questions:

What is the problem you are trying to solve?
What is your preferred solution and why do you believe this is the best option?
What alternatives did you consider?
What's the best fallback/back up plan?

jcalderazi commented 6 years ago

@JayPanoz what if we generate a simple example and a more complex one?

JayPanoz commented 6 years ago

@jcalderazi That’s a good idea, as the simple example can be used to introduce fundamental a11y practices without too much noise, I guess.

But then we should really define complex, as long tables can already create huge rendering issues in fragmentation (e.g. text being cut-off, even seen recalc happen 2 minutes after the table was first painted because fragmentation doesn’t like vertical padding for cells it seems, etc.).

That said, tables are quite this long-standing issue for which we don’t necessarily have bulletproof solutions, even for the simplest ones. I know we prototyped solutions 2 years ago with @llemeurfr but it was quite a lot of work to get it working in scroll + 2 predefined RSs already – and required JS. But I can’t tell whether there’s been other R&D on that, unfortunately. :-/

llemeurfr commented 6 years ago

I’m sure that the prototype Jiminy created for EDRLab (and the OECD / OCDE *) is worth discussing regarding how complex tables can be "prepared" by EPUB authors to appear correctly in Reading Systems.

it was for a presentation at the EPUB Summit in Brussels; Toby Green from the OECD had told us that the use of EPUB 3 at OECD was sparse because some artifacts like complex tables were of represented as they could. So Jiminy modified an OECD report so that tables (and term definitions) would be more sexy. The video of the presentation is here https://www.youtube.com/watch?v=8YkYBmh8YWM&t=22m.

Best regards Laurent Le Meur EDRLab

Le 18 mai 2018 à 10:01, Jiminy Panoz <notifications@github.com mailto:notifications@github.com> a écrit :

@jcalderazi https://github.com/jcalderazi That’s a good idea, as the simple example can be used to introduce fundamental a11y practices without too much noise, I guess.

But then we should really define complex, as long tables can already create huge rendering issues in fragmentation (e.g. text being cut-off, even seen recalc happen 2 minutes after the table was first painted because fragmentation doesn’t like vertical padding for cells it seems, etc.).

That said, tables are quite this long-standing issue for which we don’t necessarily have bulletproof solutions, even for the simplest ones. I know we prototyped solutions 2 years ago with @llemeurfr https://github.com/llemeurfr but it was quite a lot of work to get it working in scroll + 2 predefined RSs already – and required JS. But I can’t tell whether there’s been other R&D on that, unfortunately. :-/

dauwhe commented 5 years ago

From @gregoriopellegrino via email:

Dear CG, recently at Fondazione LIA we have been working on an accessible EPUB 3 with technical content. We realized that different reading systems have problems displaying complex tables that, although correctly structured in HTML and CSS, are cut in the reading mode (attached some screenshots of example).

We have been confronted with Jiminy Panoz and EDRLab not finding a practical solution applicable.

In our opinion we should find guidelines for EPUB authors and reading solutions, since more and more content producers want to produce academic, professional, scientific and not only narrative texts in EPUB.

What could be the right way forward? Identify tables with particular attributes (ARIA or epub:type) for correct identification by reading solutions? Any other ideas?

A good starting point could be the intervention of Toby Green, OECD (Organisation for Economic Co-operation and Development) at EPUB SUMMIT 2017: https://www.youtube.com/watch?v=8YkYBmh8YWM#t=36m25s

dauwhe commented 5 years ago

Identify tables with particular attributes (ARIA or epub:type) for correct identification by reading solutions?

I'm not sure how this would work, and I'm a bit wary of adding information outside of CSS that might impact rendering.

I think we have two problems--how to encourage responsive table designs, and how to prevent them from being destroyed by fragmentation and other reading system interventions.

gregoriopellegrino commented 5 years ago

You're right.

The fact is that the approach for the creation of navigable responsive tables is currently based on JavaScript solutions and many reading solutions do not support the JS.

We should find a robust solution that works on the different reading solutions without having to test them all.

llemeurfr commented 5 years ago

@gregoriopellegrino If we find a solution based on advanced CSS, we may have the same issue. I fear there will be no solution for user agents which don't implement modern technologies.

JayPanoz commented 5 years ago

As a quick reminder, don’t forget that when user agents implement modern technologies, you can’t even rely on media queries for responsive – due to “pagination” implementations’ idiosyncrasies e.g. 2-column spreads, web view being flattened so the width of the window may be 45000px, etc.

JayPanoz commented 4 years ago

Relevant when it comes to a11y, as it applies in a lot of RSs relying on browsers’ rendering engine: https://speakerdeck.com/edds/what-even-is-a-table-a-quick-look-at-accessibility-apis

gregoriopellegrino commented 4 years ago

Thanks.

The problem with big tables is essentially visual, so screen readers should always be able to access the data (even if the table doesn't fit the window).

It is different if we start to hide columns using CSS display: none: usually screen readers ignore hidden elements.

JayPanoz commented 4 years ago

Ah yeah no to clarify it was more about the second half (here’s the video) i.e. “Hey so funny story, there’s a lot of heuristics in rendering engines and your <table> is not guaranteed to have a role of table because at some point, people were using those to lay out pages on the web.”

The presenter is working at gov.uk so all his testing probably influenced those guidelines for instance – as well as other experts.

w3c / publ-cg