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

> 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 <mailto:john@foliot.ca> >
Date: Monday, January 16, 2023 at 11:46 PM
To: matt.garrish@gmail.com <mailto:matt.garrish@gmail.com>
<matt.garrish@gmail.com <mailto:matt.garrish@gmail.com> >
Cc: John Foliot <john@foliot.ca <mailto:john@foliot.ca> >, Avneesh Singh
<avneesh.sg@gmail.com <mailto:avneesh.sg@gmail.com> >, public-epub3@w3.org
<mailto:public-epub3@w3.org>  <public-epub3@w3.org
<mailto:public-epub3@w3.org> >, public-publishingcg@w3.org
<mailto:public-publishingcg@w3.org>  <public-publishingcg@w3.org
<mailto:public-publishingcg@w3.org> >, epub-higher-education@lists.daisy.org
<mailto:epub-higher-education@lists.daisy.org>
<epub-higher-education@lists.daisy.org
<mailto: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
<mailto: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 <mailto:john@foliot.ca> > 
Sent: January 16, 2023 5:28 PM
To: matt.garrish@gmail.com <mailto:matt.garrish@gmail.com> ; Avneesh Singh
<avneesh.sg@gmail.com <mailto:avneesh.sg@gmail.com> >
Cc: John Foliot <john@foliot.ca <mailto:john@foliot.ca> >;
public-epub3@w3.org <mailto:public-epub3@w3.org> ;
public-publishingcg@w3.org <mailto:public-publishingcg@w3.org> ;
epub-higher-education@lists.daisy.org
<mailto: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,  <https://www.w3.org/TR/WCAG21/#dfn-structure> structure, and
<https://www.w3.org/TR/WCAG21/#dfn-relationships> relationships conveyed
through  <https://www.w3.org/TR/WCAG21/#dfn-presentation> presentation can
be  <https://www.w3.org/TR/WCAG21/#dfn-programmatically-determinable>
programmatically determined 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
<mailto: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 <mailto:john@foliot.ca> > 
Sent: January 16, 2023 2:10 PM
To: public-epub3@w3.org <mailto:public-epub3@w3.org> ;
public-publishingcg@w3.org <mailto:public-publishingcg@w3.org> ;
epub-higher-education@lists.daisy.org
<mailto: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"