Call for testers for Sigil 2.6.0 - Beta 2

[philja]

Originally Posted by KevinH

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!

Works well and no further comments from me.

I must add thanks for your tip on using

xattr -d com.apple.quarantine <filename>

on my MacBook and also thanks to all for the creation of the AppImage for linux. After download, it takes less than a minute to swap it to my AppImage directory, check the sha256 checksum, make it executable, update-edit the OS launcher. Every time, I marvel at this little miracle.

I look forward to the official release with Becky's icons.

[KevinH]

And thank you for testing and reporting back bugs! They have helped immensely.

And the AppImage work was 100% DiapDealer! So all thanks to him!

FWIW, I consider his AppImage work to be the best thing anyone has done for Sigil in quite a long time. It finally allows us to release a version that works across many Linux distributions that has the exact same capabilities and Qt bug fixes that we give to our Mac and Windows versions. We are no longer at the whims of the Linux distributions that regularly dismantle Sigil into pieces that not everyone installs or even can install (ie. PySide6 anyone?), while adding their own patches willy nilly depending on what they want.

[KevinH]

Quick Question: what do most people use basis for a link that is a return from a footnote or endnote?

In the Aria Clips tool, it currently uses the footnote number .ie [1] to create the back link to the original text that was footnoted.

But based in some searching, it appears there is an official return unicode character designed just for this purpose:

https://www.compart.com/en/unicode/U...%2520Character

⏎

It is typically located immediately *after* the text of the footnote itself.

Should I modify the Aria Clips to use that symbol instead? It may things easier for screen readers if it uses the official backlink symbol that was specifically created for it.


Thoughts?

[Doitsu]

I'd prefer this symbol: ↩ (U+21A9)

Since screen readers might read the name of Unicode character (=leftwards arrow with hook), an aria-hidden attribute might be useful. So a slightly over-engineered example might look like this:

<a epub:type="backlink" role="doc-backlink" href="#ref1" aria-label="Back to footnote reference 1">
  <span aria-hidden="true">↩</span>
</a>

However, I don't know how well aria-hidden="true" is supported. Maybe you could test it with VoiceOver on your Mac.

[KevinH]

Would you put that immediately after the text of the footnote or before? If we hide it, then how would the accessible reader know there was a backlink?

Do people like this better than using the backlink on the footnote number itself?

Is your Accessibility Checker plugin happy with either or both?

[BeckyEbook]

In this issue is interesing discussion.
Linked sources are also valuable.

[KevinH]

Originally Posted by BeckyEbook

In this issue is interesing discussion.
Linked sources are also valuable.

Yes I was just reading the same thing! They do not like using single unicode characters as links at all because they are not unique and can not be easily interpreted.


They seem to like the following immediately after the text of the footnote as backlink text.

"Return to [1]"

As it is unique to the backlink so the user can tell various backlinks apart.

It is a good discussion!

We can do a "Return to [1]" approach I think. It should not need a new aria-label as it has the proper doc-backlink Aria role assigned.

They seem to be ignoring the aria doc-backlink role for some reason.

I will try to code up our Aria Clips to use that approach so people can test it.

[Doitsu]

Originally Posted by KevinH

Is your Accessibility Checker plugin happy with either or both?

I only tested the attached version which passes EPUBCheck (except for the backlink usage message) and ACE 1.3.7.

Spoiler:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" lang="en-US" xml:lang="en-US">
<head>
  <title>footnote example</title>
</head>

<body>
  <h1 epub:type="subtitle" role="doc-subtitle">Footnote sample</h1>

  <p>This is a reference to the first footnote<a epub:type="noteref" role="doc-noteref" href="#note1" id="ref1">1</a>.</p>

  <p>And this is a reference to the second footnote.<a epub:type="noteref" role="doc-noteref" href="#note2" id="ref2">2</a></p>

  <section aria-label="Footnotes">
    <aside id="note1" epub:type="footnote" role="doc-footnote">
      First footnote. <a epub:type="backlink" role="doc-backlink" href="#ref1" aria-label="Back to footnote reference 1"> <span aria-hidden="true">↩</span> </a>
    </aside>

    <aside id="note2" epub:type="footnote" role="doc-footnote">
      Second footnote. <a epub:type="backlink" role="doc-backlink" href="#ref2" aria-label="Back to footnote reference 2"> <span aria-hidden="true">↩</span> </a>
    </aside>
  </section>
</body>
</html>

BTW, ACE now wants a language attribute on the <package> tag.

<package version="3.0" unique-identifier="BookId" xml:lang="en-US" xmlns="http://www.idpf.org/2007/opf">

It'd be helpful if Sigil added one for new epub3 books.

[KevinH]

Actually my Access-Aid plugin handles that, as well as filling in title tags in head, and making it easy to fill in image alt attributes.

So we have that covered.

I am now leaning towards not using a single character for the backlink and not using an aria-label and instead using Return to in the text as that explains what is going on and is unique.

I am going to push that change to master and then try both epubcheck and your Ace accessibility checker on it.

[KevinH]

The only issue with that is "Back to footnote reference 1" is it is a lot of text and may be even longer than the footnote itself!

It seems to look horrible too.

Maybe using an aria-label and a single unicode character would make sense? But if it is aria-hidden="true" what actually does the user click on "verbally" since there is nothing that is spoken. I sighted person could easily click on the link.

What am I missing?

[KevinH]

So with all the doc-endnote and doc-noteref and doc-footnote aria roles, do we still need aria-label in these cases. Shouldn't the aria role tell the screen reader what this is?

Then why use role=doc-* anything? if an aria-label tells you the same thing.

This is so very confusing.

[KevinH]

I have been reading up on links and returns from footnotes and the answers are not clear.
Although aria-label replaces the text of that node for Accessibility readers, it does not do that for Screen readers. In addition, using a single unicode character for the return link simply does not provide a big enough link area for that who have muscle or motion control issues.

Accessibility, it seems, covers many many dimensions.

The simplest answer is to use physical text to form the return link big enough for touch and mouse activation and that tells the person what clicking that link will do. Then an aria-label becomes redundant as the link text tells you enough.

Based on all of this reading, I think using a single unicode character as the basis for return link is not a good idea (especially for screen readers and for those with muscle/motion control issues).

So a footnote reference link minimum length becomes 3 characters long [N] making it clickable.

And I will make the backlink text "Return to [1]" (obviously translated to the Book's language), with no extra aria-label since the link text says enough and is unique.

And as I said I will make the Reference to the footnote to be "[1]" but this time add an aria-label that says "To Footnote 1" (again properly translated).

That should hopefully make accessibility readers, screen readers, and those with muscle or motion control issues all happy.

Thoughts?

[philja]

Originally Posted by KevinH

I have been reading up on links and returns from footnotes and the answers are not clear.
Although aria-label replaces the text of that node for Accessibility readers, it does not do that for Screen readers. In addition, using a single unicode character for the return link simply does not provide a big enough link area for that who have muscle or motion control issues.

Accessibility, it seems, covers many many dimensions.

The simplest answer is to use physical text to form the return link big enough for touch and mouse activation and that tells the person what clicking that link will do. Then an aria-label becomes redundant as the link text tells you enough.

Based on all of this reading, I think using a single unicode character as the basis for return link is not a good idea (especially for screen readers and for those with muscle/motion control issues).

So a footnote reference link minimum length becomes 3 characters long [N] making it clickable.

And I will make the backlink text "Return to [1]" (obviously translated to the Book's language), with no extra aria-label since the link text says enough and is unique.

And as I said I will make the Reference to the footnote to be "[1]" but this time add an aria-label that says "To Footnote 1" (again properly translated).

That should hopefully make accessibility readers, screen readers, and those with muscle or motion control issues all happy.

Thoughts?

I confess to always having made the backlink text [1], but I can see this might be a small target for those with muscle control issues.

I've always just done the same thing in the text when making a link to a footnote - except I wrap the [1] in <sup> tags in an attempt to improve its visibility.

There's clearly a balance to be struck between what is difficult for 'handicapped' people and what is annoying for 'other' people. Given the different ways epub2 is implemented by the various makers of reading devices, it is very likely that the implementation of accessibility features will be just as varied and we can't satisfy all needs. Just as print books have 'large print' versions, maybe eBooks should have regular and accessible versions?

If the implementation of <aside> results in a pop-up, there is no need for a backlink. In the meantime, I'd go for "Return to [1]" as reasonably short and simple.

[philja]

I've just noticed something curious with my MacBook. I had my test ePub3 document open in Sigil and the Aria Clip and Role buttons were greyed out and not working.

I've tried to reproduce that by starting Sigil and opening the file in different sequences, but I can't.

Something to be kept in mind.

[BeckyEbook]

Originally Posted by philja

I've just noticed something curious with my MacBook. I had my test ePub3 document open in Sigil, and the Aria Clip and Role buttons were greyed out and not working.

I guess this is the case (on Mac) where checking once when opening a file doesn't work.
Probably the visibility of the Aria icons depends on the type of file last opened; if it was epub2 then the icons went gray.