search

daisy / ebraille

Repository for developing use cases and standard for digital braille
16 stars 4 forks source link

Explain navigation elements in more detail #181

Closed mattgarrish closed 3 weeks ago

mattgarrish commented 1 month ago

Not much to add to the title. Expands each of the nav sections to include more detail about their use.

clapierre commented 1 month ago

Matt, I would suggest including a <h1> for each of these (TOC, Page List, Landmarks, etc.) and have the <nav> point to it using aria-labelled by as each Nav must have a unique heading which is fine if there is only one <nav> in the file but when there are multiple its better to show the explicit headings for each.

Eg.
<nav aria-labelledby="toc" ...>
   <h1 id="toc">Table of Contents</h1>
   ...

<nav aria-labelledby="pagelist"...>
   <h1 id="pagelist>Page List</h1>
   ...

etc.
mattgarrish commented 1 month ago

Ah, right, I wasn't focused on headings and they may need to be rendered for web deployment.

But headings are only required if there are multiple of the same role, not the same element, and you can't have more than one of each of these nav types, so a heading is not absolutely necessary from a machine processing point of view. If you only have these three, they'd be identified as the table of contents, page list, and probably a generic navigation region.

mattgarrish commented 1 month ago

Actually, this doesn't seem right. The headings should be in braille if they're for web rendering and there should probably be aria-label attributes with the plain language names for AT.

mattgarrish commented 1 month ago

I've updated the page list to require the title attribute. Do you think we need to say that the navigation document should be encoded in braille or does that stand to reason given the nature of the format? (I'm assuming we shouldn't need to say anything more.)

Also, can you double-check the examples for me, @wfree-aph? I did a character-to-character translation so may have got things wrong, or at least suboptimal.