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
isn't authored with anchor tags, the "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" 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"). 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"