Re: Seeking *opinions* as part of a larger research issue.

Hi there, thanks for the interesting discussion here - I just wanted to
highlight that for me, including "deadlinks" in our ePubs is not an option
(at least during the initial release of a publication), as we could get our
titles suppressed from sale by partners if an ePub is found to include
deadlinks.

For this reason it is part of our QA to test all external hyperlinks to
ensure no deadlinks are present.

For our travel guides, that include hundreds of hyperlinks per title, we
even have web crawler scripts that automate this validation process (that
we run on every revision cycle).

While the ePub is on-sale though, there is nothing we can do to avoid
websites getting shut down, so the only way for us to become aware of
deadlinks is when users flag the issue with the retailers and they then
raise those issues with us through their portals or error reports sent via
email. We then revise the ePub and release the revised version, as and when
required.

With the examples above in mind I would say that the best practice here
would be to make publishers aware (and especially self publishing authors
with more limited resources and technical knowledge) that this could be a
potential issue and that it would be their responsibility to ensure
external hyperlinks in the ePub are always validated before release, even
if it means updating the URLs of an old backlist title.

Miguel

On Tue, 17 Jan 2023 at 21:39, <matt.garrish@gmail.com> wrote:

> > For 'dead links' I tend to be with Lisa: "...*keep the links as is, as
> that was the original way it was done (similar to print).*"
>
>
>
> Link rot is a huge problem that’s been in search of a solution for a long
> time. Persistent URLs, wayback machine, etc. all have a role, but you may
> never even get the chance to fix an EPUB. Only if the link has gone dead
> before you publish do you often have the opportunity to do anything about
> it. If you’re publishing a new edition, the author would hopefully update
> their references, but if it’s a backlist title that has to be published
> as-is, then leaving the link to the dead resource is all you can do.
>
>
>
> I don’t have a strong an opinion on this case because the user can take
> the information and seek out cached versions, so it’s not as problematic to
> me as sending them to a site that never existed in the first place (or
> sending them to a namespace or whatever has been wrongly captured). It’s
> not as obviously an accessibility or usability issue, at least.
>
>
>
> Matt
>
>
>
> *From:* John Foliot <john@foliot.ca>
> *Sent:* January 17, 2023 4:25 PM
> *To:* matt.garrish@gmail.com
> *Cc:* Reid, Wendy <wendy.reid@rakuten.com>; John Foliot <john@foliot.ca>;
> Avneesh Singh <avneesh.sg@gmail.com>; public-epub3@w3.org;
> public-publishingcg@w3.org; epub-higher-education@lists.daisy.org
> *Subject:* Re: Seeking *opinions* as part of a larger research issue.
>
>
>
> Hi Matt
>
>
>
> > But if you control the workflow and you can find ways to mitigate the
> problem, like having authors tag/style inactive URLs a certain way so a
> processing script doesn’t try to add tagging, it’s definitely an easy way
> to improve the reading experience.
>
>
>
> FWIW, this is exactly the scenario I am faced with today - a workflow
> process. (That's one of the reasons why I liked your "use the <code>
> element" suggestion, as that would be the 'hook' that tells processing
> scripts to ignore the string of text that "looks" like a URL).
>
> What I am also seeing however is an emergent consensus about a specific
> authoring pattern and expected behaviors (i.e., I'm not hearing anyone
> argue to make 'fake' urls active, although 'deadlinks' is a different
> scenario which publishers may have less control over. For 'dead links' I
> tend to be with Lisa: "...*keep the links as is, as that was the original
> way it was done (similar to print).*").
>
>
>
> This prompts the question, should we (have we?) formalized this somewhere?
> I personally think the negative impact here could rise to the level of it
> being an accessibility barrier for some users (and could advocate taking
> this to the ePub Accessibility TF), but it also strikes me that this is a
> potential issue for non-disabled users as well - which would suggest
> capturing the expected outcome in the ePub 3 spec text directly (somehow,
> somewhere - perhaps as a Editor's Note - although Notes are usually
> non-normative as well... But please take my larger point.)
>
> I just think that a) I looked hard for an answer before bringing this
> issue to the group to seek your opinions, b) we all seem to be in agreement
> as to expectations, c) capturing that agreement for the 'next time'
> somebody asks the same or similar question, just makes sense.
>
> Open to how to move the idea forward. (If in fact it is worth doing)
>
> JF
>
>
>
> On Tue, Jan 17, 2023 at 2:43 PM <matt.garrish@gmail.com> wrote:
>
> > One challenge to this may be how most word processing tools (that might
> then convert to EPUB or other formats) auto-format anything that looks
> remotely like a URL
>
>
>
> This is a big problem, I find, too. I doubt most authors think, hm, I
> better make this fake URL active so readers can get a 404 page when they
> click on it. It’s applications trying to be “helpful” that end up making a
> mess, especially if the author isn’t savvy enough to undo the formatting.
>
>
>
> But if you control the workflow and you can find ways to mitigate the
> problem, like having authors tag/style inactive URLs a certain way so a
> processing script doesn’t try to add tagging, it’s definitely a easy way to
> improve the reading experience.
>
>
>
> Matt
>
>
>
> *From:* Reid, Wendy <wendy.reid@rakuten.com>
> *Sent:* January 17, 2023 4:56 AM
> *To:* John Foliot <john@foliot.ca>; matt.garrish@gmail.com
> *Cc:* John Foliot <john@foliot.ca>; Avneesh Singh <avneesh.sg@gmail.com>;
> public-epub3@w3.org; public-publishingcg@w3.org;
> epub-higher-education@lists.daisy.org
> *Subject:* Re: Seeking *opinions* as part of a larger research issue.
>
>
>
> I may take the dissenting opinion here as this needing to be something we
> put effort into in regard to best practices but I don’t dissent on
> everything.
>
>
>
> In the example of someone using a placeholder URL and formatting it as
> such in text, I think we’re missing that there would be context.
>
>
>
> For instance, if I am writing a book about coding and in one of my
> examples I use a placeholder URL and make it clear that that is what it is,
> I don’t think it’s an issue, because context has been provided. As to
> whether the placeholder should be formatted as a URL, though not coded like
> one (using CSS to underline vs <a>), I think that is also contextual.
>
>
>
> If it’s a fake URL on its own in isolation, or in a misleading context, I
> see a problem.
>
>
>
> One challenge to this may be how most word processing tools (that might
> then convert to EPUB or other formats) auto-format anything that looks
> remotely like a URL, and authors either then have to remove the formatting,
> or be cognizant of altering it in HTML to make sure it’s just styled not
> anchored.
>
>
>
> -Wendy
>
>
>
> *From: *John Foliot <john@foliot.ca>
> *Date: *Monday, January 16, 2023 at 11:46 PM
> *To: *matt.garrish@gmail.com <matt.garrish@gmail.com>
> *Cc: *John Foliot <john@foliot.ca>, Avneesh Singh <avneesh.sg@gmail.com>,
> public-epub3@w3.org <public-epub3@w3.org>, public-publishingcg@w3.org <
> public-publishingcg@w3.org>, epub-higher-education@lists.daisy.org <
> epub-higher-education@lists.daisy.org>
> *Subject: *Re: Seeking *opinions* as part of a larger research issue.
>
> *[EXTERNAL] *This message comes from an external organization.
>
> LOL... gotcha.
>
>
>
> Ya, if you squint the right way, one could certainly fail it because
> "...you've created, or created the impression, that the text is something
> it is not" under SC 1.3.1, because 1.3.1 is all interpretation with no
> actual measurable requirements. (Again, you are taking an inference -
> actually a negative inference - from the normative text, which is far less
> precise.)
>
>
>
> Sadly however, while you and I may agree on this interpretation, that is
> not a given for all - I'm fairly certain we could find someone to disagree
> with our interpretation somewhere. (And while I've not conducted any kind
> of search, I'd be curious to know if anyone reading this had ever done that
> before, failed a similar use case using the reasoning you presented.)
>
> JF
>
>
>
> On Mon, Jan 16, 2023 at 5:23 PM <matt.garrish@gmail.com> wrote:
>
> > OMG, that is the worst SC known to man, as it is both vague, broad, and
> open to all sorts of interpretations.
>
>
>
> Fully agree with you!
>
>
>
> > *But the real issue is that what it *appears* to be conveying is in
> fact not true*
>
>
>
> Right, I probably wasn’t clear but this is what I was asking. If you tag a
> sample URL as a hyperlink, or even style it to look like it’s active, isn’t
> that a violation of 1.3.1? You’ve created, or created the impression, that
> the text is something it is not.
>
>
>
> I consider it like using heading tags for formatting.
>
>
>
> Matt
>
>
>
> *From:* John Foliot <john@foliot.ca>
> *Sent:* January 16, 2023 5:28 PM
> *To:* matt.garrish@gmail.com; Avneesh Singh <avneesh.sg@gmail.com>
> *Cc:* John Foliot <john@foliot.ca>; public-epub3@w3.org;
> public-publishingcg@w3.org; epub-higher-education@lists.daisy.org
> *Subject:* Re: Seeking *opinions* as part of a larger research issue.
>
>
>
> Thanks Matt!
>
> Your suggestion of using <code> tags is both interesting and helpful. Will
> mull that one over a bit more and take back to the team.
>
> As to whether this is addressed in SC 1.3.1 - OMG, that is the worst SC
> known to man, as it is both vague, broad, and open to all sorts of
> interpretations. That SC normatively states:
>
>
>
> Information, structure
> <https://www.w3.org/TR/WCAG21/#dfn-structure>,
> and relationships
> <https://www.w3.org/TR/WCAG21/#dfn-relationships> conveyed
> through presentation
> <https://www.w3.org/TR/WCAG21/#dfn-presentation> can
> be programmatically determined
> <https://www.w3.org/TR/WCAG21/#dfn-programmatically-determinable> or
> are available in text.
>
>
>
> Now, the issue is multi-fold here: first, even if www.FakeUrl.com
> <http://www.FakeUrl.com>
> isn't authored with anchor tags, the "fakeurl.com
> <http://fakeurl.com>"
> bit visible on screen *IS* "...available in text" - text that even screen
> readers would hear. So it's not a failure in MHO.
>
>
>
> And in the inverse - .if the text string links to nothing but still
> appears and acts like a link - it would be hard to argue that it wasn't
> conveying *something* via presentation that is also programmatically
> available due to the <a> element being used (styled or unstyled, as
> user-agents or CSS generally styles the <a> element differently than
> non-link text). *But the real issue is that what it *appears* to be
> conveying is in fact not true* - but the "is it true and/or accurate"
> part is not part of the normative text...
>
>
> But most importantly, when a content author writes "www.FakeUrl.com
> <http://www.FakeUrl.com>"
> there is an author-intent there that is not explicitly code-determinable:
> It *MAY* be conveying a relationship through presentation (i.e it is an
> actual link - unstyled it would be blue with the text underlined), or it
> may just be conveying a text string in a format that has no specific
> relationship to anything else, but is instead just *an editorial example*..
> Parsing engines and accessibility testing tools could never be fully sure
> of the author intent (which is why your suggestion of using <code>  piqued
> my interest, as it would be one method for the author to convey the intent
> - at least partially).
>
> I think I may take this back to Avneesh and the ePub Accessibility TF -
> there may be some real meat on this bone to craft a new requirement (or at
> least a Best Practice) around.
>
> JF
>
>
>
> On Mon, Jan 16, 2023 at 2:58 PM <matt.garrish@gmail.com> wrote:
>
> Hi John,
>
>
>
> > should those text strings STILL be marked up as hyperlinks?
>
>
>
> Technically, you can markup them up as inactive hyperlinks (a without an
> href), but your first example doesn’t really even qualify as that.. I
> wouldn’t do anything special with dummy URLs, to be honest, except maybe
> mark them with code tags.
>
>
>
> Doesn’t this fall under 1.3.1 info and relationships, though? When you
> have text that only looks like a URL but is not meant to be followed,
> marking it as a hyperlink would seem to violate the principle (i.e., it
> adds info that doesn’t actually exist). I don’t know if that SC makes
> unnecessary tagging a violation – I’ve always seen it enforced for adding
> missing structure – but there’s an argument that it should capture
> misapplied tagging. It’s probably not something we’d take up in the EPUB
> accessibility spec, as it’s not specific to ebooks.
>
>
>
> Agree with everything you’ve already said about the annoyance and
> confusion factors. I’d only add that it’s annoying to everyone, not just
> persons with disabilities. It makes you wonder if there is some reason why
> the link is there and whether you should follow it just to see where it
> goes.
>
>
>
> Matt
>
>
>
> *From:* John Foliot <john@foliot.ca>
> *Sent:* January 16, 2023 2:10 PM
> *To:* public-epub3@w3.org; public-publishingcg@w3.org;
> epub-higher-education@lists.daisy.org
> *Subject:* Seeking *opinions* as part of a larger research issue.
>
>
>
> The use-cases are pretty simple:
> 1) an ePub book has text content on the page that is a URL (i.e. it quite
> literally reads "www.examplesite.com
> <http://www.examplesite.com>").
> The URL does not (and is not expected to) actually resolve anywhere, it's
> just an example or placeholder text.
> 2) an ePub book has content on the page that was once an active hyperlink,
> but the link no longer exists.
>
> The question is: for both of those use-cases (where the "print" is
> offering up a text string formatted as an URL, but there is no actual URL
> to resolve to), should those text strings STILL be marked up as hyperlinks?
>
> From a strict conformance to WCAG perspective… well, WCAG is silent on
> this specific topic (and so it seems is ePub Accessibility 1.1).
> I strongly suspect that there are arguments for both sides of the
> discussion (“should all printed URL’s be active links”?), but I am
> currently backing the perspective that having users (readers) follow
> inactive links (or presenting users with inactive links to follow),
> a) potentially places negative cognitive strain and confusion on some
> users,
> b) potentially demands unnecessary interactions (clicking a useless link)
> that could be problematic for mobility impaired users, and
> c) delivers zero quality for any effort invested by the user.
>
> My questions are:
> 1) do you agree or disagree with my reasoning? (If you disagree, might I
> ask for your counter-argument please?)
>
> 2) have you encountered this before? If you have, can you tell me what you
> ended up doing? In particular, if you work in EDU (office of accommodation,
> etc.) where ePub remediation is part of your work/tasks, do you have a
> 'standard' policy or solution to either of these use cases?
>
> 3) any other thoughts or comments? (Note: we're looking for a solution
> that is also scalable, FWIW)
>
> Thanks in advance for any feedback!
>
>
> JF
>
> --
>
> *John Foliot* |
> Senior Industry Specialist, Digital Accessibility |
> W3C Accessibility Standards Contributor |
>
> "I made this so long because I did not have time to make it shorter." -
> Pascal "links go places, buttons do things"
>
>
>
>
> --
>
> *John Foliot* |
> Senior Industry Specialist, Digital Accessibility |
> W3C Accessibility Standards Contributor |
>
> "I made this so long because I did not have time to make it shorter." -
> Pascal "links go places, buttons do things"
>
>
>
>
> --
>
> *John Foliot* |
> Senior Industry Specialist, Digital Accessibility |
> W3C Accessibility Standards Contributor |
>
> "I made this so long because I did not have time to make it shorter." -
> Pascal "links go places, buttons do things"
>
>
>
>
> --
>
> *John Foliot* |
> Senior Industry Specialist, Digital Accessibility |
> W3C Accessibility Standards Contributor |
>
> "I made this so long because I did not have time to make it shorter." -
> Pascal "links go places, buttons do things"
>


-- 

*Miguel Cunha*
Global Lead for eBook Technology and Design
My pronouns: he/him/his

One Embassy Gardens, 8 Viaduct Gardens, London, SW11 7BW
+44 (0) 20 7139 *2088*
www.dk.com
<http://www.google.com/url?q=http%3A%2F%2Fwww.dk.com&sa=D&sntz=1&usg=AFQjCNFL-NLyn75sLY8EcwxTNn9bun6pMg>


IMPORTANT NOTICE: This email is sent on behalf of Dorling Kindersley Limited, a company registered in England and Wales with number 1177822, of One Embassy Gardens, 8 Viaduct Gardens, London, SW11 7BW.  DK is a company in the Penguin Random House division of Bertelsmann SE.

The contents of this e-mail may contain information that is confidential, and its contents may only be used by the intended recipient(s) for any agreed purposes.  The contents of this e-mail may not be used, copied or disclosed outside such agreed purposes. 

If you have received this e-mail in error, please notify the sender immediately and then delete this e-mail.

Please consider the environment before printing this email