Consider adding explicit semantics for representing poetry to facilitate reading with assistive technologies, indication of lines, stanzas, etc.

[jnurthen]

From @jasonjgw on January 30, 2017 15:17

Currently, there is no standard approach to marking up poetry. I think this would be an appropriate topics for consideration in developing the next version of the DPUB ARIA module, enabling assistive technologies or accessible e-book reading systems to facilitate reading and navigation by the user.
See https://www.w3.org/html/wg/wiki/PoeticSemantics
for prior work on this topic.

Copied from original issue: w3c/aria#519

[TzviyaSiegman]

Publishing WG has agreed that the next version of DPUB-ARIA will be a maintenance release. I think adding information about reading poetry/stanzas is extremely valuable. This is as much a CSS issue as it is an ARIA issue. /cc @IanPouncey

[dauwhe]

If such markup existed, how would assistive technologies use it? What behaviors do you hope to see?

[deborahgu]

I second @dauwhe's question. Poetry markup would presumably be primarily of assistance to screen reader users (I'm trying to think of use cases for non-vision related AT for this one and at the moment I can't). Has anyone at DAISY or elsewhere done work on desired behavior for a screen reader when poetry is reached? Would it just be an announcement that the block of text is a poem, or would the markup do something special in the case of, say, concrete poetry, calligrams, any of the myriad forms of visual poetry, or poems which can be read in multiple ways? How much poetry markup are we hoping for?

My inclination would be that the best you could reasonably do, given the nature of poetic experimentation, would be to mark a block as poetry and then possibly have something analogous to an alt attribute to explain more information. So doc-poem could report a block is a poem. doc-poem alt="vilanelle" wouldn't be very useful but would be possible, and doc-poem alt="concrete poem shaped like a mouse tail with text shrinking as it procedes" would be very helpful, and in theory there could even be doc-poem details=link where link says

A three column poem that can be read across all the lines, or down each column. Here are the three poems read in each of those formats:

reading left to right

this is my poem ...

Also I could see a use case, for when in a block labelled doc-poem, for a screen reader choosing to pause at line breaks or more than one non-breaking space.

Obviously I've just described here a mix of markup wish lists and AT ideal behavior wish lists, but I think we need to before we randomly propose markup. What behaviors could we plausibly markup that AT could plausibly support?