Missing best practices for correctly tagging examples in Styling Best Practices

[bertfrees]

We have a number of examples in the Styling Best Practices that are currently (possibly) not marked up correctly because there are no tagging best practices for these cases yet:

• [x] Number line: currently handled with a pre ~but that is probably not what we want.~ (for now there is no better alternative)
• [ ] Spatial math: currently handled with a pre but that is probably not what we want.

Since above two seem to be cases of spatial materials, should https://github.com/daisy/ebraille/issues/30 not have been closed yet?

• [x] Centered heading with a title and subtitle on different lines: I currently do this with a header that contains a h1 and a p, but is this indeed what we want to recommend?

  <header>
   <h1>⠠⠞⠊⠞⠇⠑⠒⠀</h1>
   <p>⠎⠥⠃⠞⠊⠞⠇⠑</p>
  </header>

[wfree-aph]

@bertfrees Thanks for pointing out these discrepancies. I am not sure what to do about number lines and spatial math at the moment. In group discussions we have considered pre to be an acceptable solution for MVP- though certainly not ideal. Do you have any proposals for how we could address them?

One idea is that we mark up each individual element. This all starts to get very complicated because these are both handled differently in different parts of the world but I'll stick with BANA for this discussion.

So for a number line, you'd potentially need to tag the line itself, the individual numbers associated with that line, any labels, any interval. This option would assume that you wanted to keep the braille characters exactly as they were originally created even if the formatting changes, which may not be ideal.

The other option is that you have the number line's "instructions" embedded in the tags. I don't know how this would work but I'm imagining you have some tags that indicate that a number line is needed at this location and it gives the values associated with that number line. So rather than hardcoding the braille, you'd indicate the count, the line start, line end, interval start, interval end, and any labels within the tag only and then the CSS would need to handle building that number line according to the users' braille region and display size. I don't know if this would work and it seems really messy. It also requires some translation or at least hardcoding the translation of aspects of the number line, similar to how we hardcode the translation of page numbers within the tags.

You'd then do something similar for spatial math. You'd tag the individual parts or create tags that had enough information for the CSS to build the spatial math.

What do you think of those solutions?

For the header with h1 and p tags, I'm not sure here either. Braille has rules for titles and subtitles, so it makes sense to identify them. Should we get more specific than h1 and p inside a header? I'll also admit that I'm confused about using header instead of h1 for the parent tag. I was imagining that we'd use h1, h2, and h3. Header was reserved for running headers, which usually appear on line 1 and aren't separated into title and subtitle on multiple lines- though I will admit that I don't know how these are handled in every braille region around the world.

[bertfrees]

I know this is going a bit off-topic, but: should we really be reserving header for running heads? header is quite a generic element that might be useful for other things. Why not do like we always do and reserve a class value for it? The class could be allowed on header, but also on h1, h2 etc., or hgroup (whatever element is semantically most suitable in the specific case). I can imagine that in some cases the running header will simply be a different presentation of a heading, either in addition to the heading within the normal flow (a duplication of the content) or instead of it (the heading within the normal flow changes into the running header and visa-versa as the reader scrolls, think of a "sticky header"). In both of these cases (but especially the latter) one could consider using a single HTML element, with a presentation that changes as the reader scrolls. Even when the running header area is limited in space, it might be doable, e.g. using an abbr attribute.

I'm not saying we should avoid separate elements for running headers at all cost, but I think sometimes it will just make more sense.

Thinking about this also made me wonder if the running header, as we know it from BRFs, will survive within dynamic braille. It may be replaced by some other (more dynamic) means of getting the current heading.

[bertfrees]

Braille has rules for titles and subtitles, so it makes sense to identify them. Should we get more specific than h1 and p inside a header?

Yes, class values for title and subtitle sound appropriate here.

The other option is that you have the number line's "instructions" embedded in the tags.

That sounds like inventing a new XML language for number lines, and definitely sounds out of scope to me. The pre approach seems the most realistic to me. Everything else quickly gets very complicated.

For spatial math, perhaps MathML can be used in some cases?

[mattgarrish]

Why not do like we always do and reserve a class value for it?

DPUB-ARIA has doc-pageheader and doc-pagefooter for running headers and footers. The only concern is that they might not make it into the final 1.1 release as so far we haven't been able to show much support for them.