Call for testers for Sigil 2.6.0 - Beta 2

[KevinH]

No rules that I know of.

How about I just add Footnote With P and Backlink to the set of existing Aria clips.

Would that work?

[KevinH]

That single set of div tags is what aria docs refer to a "footnotes section". You should insert that to wrap your p footnotes once we add a p footnote capability.

[KevinH]

Okay, I have added the footnote that uses a p tag. And if you choose an empty Section or empty Aside, the equivalent of "Insert Roles" is automatically called allowing you to choose the roles you want (ie the type of section or the type of aside you want).

So hopefully this has fulfilled everyone's feedback and comments so far.

I will post Beta 4 builds with these changes later on tonight.

Please give them a try and see if these smarter Aria Clips make good sense.

If people are generally happy, I will rebuild the base for translations so we can give everyone lots and lots of time to translate things given such a large new set of strings have been added.

[KevinH]

Okay I have posted the Beta-4 builds to:

https://github.com/kevinhendricks/Bu...OnMac/releases

Please give them a few trials and let me know if these are complete enough to move forward with.

Thank you.

[Doitsu]

Originally Posted by philja

I've tried it out with a couple of footnotes inside a single set of <div> tags and with the id's in the <p> tags and EpubCheck lets it pass ok.

Would that violate any rules?

It doesn't violate any rules, but if I understand the specs correctly, they prefer <aside> tags, wrapped in <section> tags.
(The <aside> tags may contain other block level tags such as <p>.

E.g. something like this:

  <section aria-label="Footnotes">
    <aside id="note1" epub:type="footnote" role="doc-footnote">
      First footnote. <a epub:type="backlink" href="#ref1">↩</a>
    </aside>

    <aside id="note2" epub:type="footnote" role="doc-footnote">
      Second footnote. <a epub:type="backlink" href="#ref2">↩</a>
    </aside>
  </section>

or

  <section aria-labelledby="footnotes-heading">
    <h2 id="footnotes-heading">Footnotes</h2>

    <aside id="note1" epub:type="footnote" role="doc-footnote">
      First footnote. <a epub:type="backlink" href="#ref1">↩</a>
    </aside>

    <aside id="note2" epub:type="footnote" role="doc-footnote">
      Second footnote. <a epub:type="backlink" href="#ref2">↩</a>
    </aside>
  </section>

Also see this DAISY page fore more information on aria-label and aria-labelledby.

[philja]

Tested Beta4 on my MacBook and the new variants for footnotes are very useful.

Just one query - when <section> is selected, the pop-up offers role for footnotes but epub:type only, no Aria role.

When the clip "Footnotes (footnotes)" is selected, the <section> is used + epub:type and aria role.

Perhaps that clip should include the word section in its name just like the 3 above include aside, div, P.

[KevinH]

I will look into that.

Update,

okay that is a bug in my Footnotes section clip. I checked the spec here:

https://www.w3.org/TR/dpub-aria-1.1/

And technically no "doc-footnotes" (note the plural) exists anymore. So a footnotes section may only have epub:type not an aria role.

The Insert Role handles that properly. The Insert Aria Clips did not. I will fix that.

[KevinH]

Originally Posted by Doitsu

It doesn't violate any rules, but if I understand the specs correctly, they prefer <aside> tags, wrapped in <section> tags.
(The <aside> tags may contain other block level tags such as <p>.

E.g. something like this:

  <section aria-label="Footnotes">
    <aside id="note1" epub:type="footnote" role="doc-footnote">
      First footnote. <a epub:type="backlink" href="#ref1">↩</a>
    </aside>

    <aside id="note2" epub:type="footnote" role="doc-footnote">
      Second footnote. <a epub:type="backlink" href="#ref2">↩</a>
    </aside>
  </section>

or

  <section aria-labelledby="footnotes-heading">
    <h2 id="footnotes-heading">Footnotes</h2>

    <aside id="note1" epub:type="footnote" role="doc-footnote">
      First footnote. <a epub:type="backlink" href="#ref1">↩</a>
    </aside>

    <aside id="note2" epub:type="footnote" role="doc-footnote">
      Second footnote. <a epub:type="backlink" href="#ref2">↩</a>
    </aside>
  </section>

Also see this DAISY page fore more information on aria-label and aria-labelledby.

I am confused. Those already exist. You add a "footnotes section" then fill it with "footnote with aside and backlink".

According to the spec, p is an allowed container for all aria roles, just like div.

So you can technically make a footnote with a p tag.

Also footnotes sections are rarely given a title heading, where as endnotes sections are typically given a title heading.

On Books.app , you would have a title followed by nothing as asides for footnotes are hidden, as you pointed out. That is why a "footnote with div" was added.

I can provide an aria-label though but translating it on the fly not to the ui but to the destination epub language would be a bear.

[philja]

Originally Posted by KevinH

https://www.w3.org/TR/dpub-aria-1.1/

And technically no "doc-footnotes" (note the plural) exists anymore. So a footnotes section may only have epub:type not an aria role.

The Insert Role handles that properly. The Insert Aria Clips did not. I will fix that.

Geez! What a jungle! It looks like 'accessibility' is meant to exclude authors and creatives. Endnotes can be singular or plural, but a section can only contain one footnote?

So we must have a multitude of <section>'s each having only a single footnote?
And yet a <section> can contain the whole of a chapter with multiple <p>'s. This seems like difficult reasoning.

I would imagine this will lead in practice to authors putting a <section> with the role doc-footnote and then including multiple <p>'s each with its footnote text and backlinks. Or as DiapDealer shows with multiple <aside>'s.

[KevinH]

No you misunderstand. A section can hold as many footnotes that you want. There just does not exist a role attribute to indicate this section contains footnotes but we can add an aria label to indicate that or just rely on the role assigned to each footnote leaving the section unlabelled.

The key idea behind a section is that good accessibility software will create a catalog of each section in a single file allowing the user to skip over or skip to that section easily.

So if a user has followed each footnote link and read every one, then upon reaching the end of that chapter/section they can easily skip over the entire section of already read footnotes.

Roles are not meant to be limiting by design, they are meant to be informative when used in a proper setting.

That is all.

[KevinH]

As to why there are no parallels between aria roles and epub:types I have no idea. I think aria roles spec came after the first Epub Semantic Structure Vocabulary spec.

Without that parallelism things do not make much sense at times. The rules and examples are arcane at best.

But think of a Screen Reader that sees a section with a role. If the section has a aria-label, it will announce that label and not say a generic Section role. If it has an aria-labelledby attribute that points to a heading tag, it will read that instead., etc.

The key is not to make the screen reader repeat ... saying things like "Chapter" immediately followed by "Chapter 1 A New Beginning". The latter is the one most listeners would prefer.

The sections are quickly indexed by the screen reader to help them quickly navigate among sections within a single file.

All of these arcane rules on usage and placement are trying to ease access to different sections while at the same time making Screen reading easier for the listener.

It makes a bit of sense then. But of course, loading your epub into an e-reader that supports specialized accessibility software and listening and trying to navigate is the only sure way to know you have improved accessibility.

Hope something here helps.

[KevinH]

Okay, I have removed the role "doc-footnotes" to fix the bug in the Footnotes (section). Then I renamed and organized the Aria Clips titles so they would be easier to see the natural groupings.

Then I added an aria-label="Footnotes" to what is now the Section: Footnotes clip. I have also integrated the code to translate an aria-label attribute value to be in the language of the Book, not the Sigil UI language if at all possible. But none of that infrastructure translation code will work until translators have actually generated translations for all of the new strings.

I have pushed all of these changes to Sigil master, and have created unsigned Beta-5 builds and stored them here:

https://github.com/kevinhendricks/Bu...OnMac/releases

I am truly hopeful that this will be the final Beta and that I can clean up any other nits you can find and start the process of getting translations done. With over 30 new strings in Aria Clips, and 40 new Roles and all of their Descriptions, there will be a lot of work for translations teams so hopefully within a month or so, we will have something we can release officially.

Please test this version well and report back.

Thank you!

[BeckyEbook]

I have prepared icons for "Aria Clip" and "Role".

This is how I envision these two icons:


They convince me, but if someone has a better idea, I'd love to hear it.

The icon for Aria Clip includes elements related to code (<>) and a human silhouette representing "Accessibility".

The icon for Role may be simplistic, but it is unique, hand-drawn, and refers to a similar solution – that is, the letter "M" for "Metadata Editor". I find it difficult to express "Role" in this sense graphically (and in the context of an EPUB file), hence the icon with the letter, which is a mnemonic (R for Role).

[KevinH]

Thanks! With them I could create an Aria Toolbar that could be hidden on epub2. Or did you envision icons on the menu items only?

[BeckyEbook]

Icons, of course, work on toolbars and menus.
I tested them at my build and they work OK (on the "Insert" toolbar in epub2, they are disabled).