search

w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.13k stars 256 forks source link

Link Inside OR Outside the Paragraph - Sanity check 2.4.4: Link Purpose (In Context) #1745

Open jake-abma opened 3 years ago

jake-abma commented 3 years ago

Does this one FAIL for non-contextual reasons (?!)

<li>
      <h2>Parts and Supplies</h2>
      <img class="imgl" src="images/site/small60-1.jpg">
      <p>We sell parts and supplies for every computer we sell and even some that we don't.  If we don't have a part, it doesn't exist. If it does exist and we don't have it, we'll get it.  If we can't get it, we'll steal it. That's how we roll.</p>
      <p class="readmore"><a href="support.php">Continue Reading »</a></p>
    </li>

And does this one PASS because "in" the HTML paragraph (?!)

<li>
      <h2>Parts and Supplies</h2>
      <img class="imgl" src="images/site/small60-1.jpg">
      <p>We sell parts and supplies for every computer we sell and even some that we don't.  If we don't have a part, it doesn't exist. If it does exist and we don't have it, we'll get it.  If we can't get it, we'll steal it. That's how we roll.
          <span class="readmore"><a href="support.php">Continue Reading »</a></span>
      </p>
</li>

Definition for "programmatically determined link context" surely says:

In HTML, information that is programmatically determinable from a link in English includes text that is in the same paragraph, list, or table cell as the link or in a table header cell that is associated with the table cell that contains the link.

BUT 'did' or 'did we not' define 'paragraph' as an HTML element?

Thought we did not, and the visual appearance provides the "paragraph" (also)...

... if so, do they both PASS?

CODE FROM demo Deque page: http://webtestingcourse.dequecloud.com/index.php

jake-abma commented 3 years ago

F63 specifically says they fail if 2 paragraphs are present, but the question remains if we defined a paragraph to be the<p>element?

https://www.w3.org/WAI/WCAG22/Techniques/failures/F63

JAWS-test commented 3 years ago

We have H80 - so your example might not be a failure, because the context is clear from the heading

JAWS-test commented 3 years ago

And there seem to be more areas of WCAG where a clear definition of paragraph would be useful: https://github.com/w3c/wcag/issues/1396

jake-abma commented 3 years ago

We have H80 - so your example might not be a failure, because the context is clear from the heading

its an "Advisory Techniques"

patrickhlauke commented 3 years ago

issue here is obviously the vague handwave of what is programmatically determinable, as the definition just says "includes" ... so not an exhaustive list ... but then never goes further in giving other examples. I personally would pass it based on the heading (edit: and the fact that it's all inside a list item, so a container that is well defined, rather than just a generic <div> or something) ... "advisory" or not.

bruce-usab commented 3 years ago

Yes, with the 2nd example at OP, the P with the link is in the same LI as the description, so one could argue that is the same element, so there is your context. I don't think that is good enough! The second F63 failure example is a simple table. Why would LI be okay as the parent element, but TABLE is not? Seems like the core expectation is that 2.4.4 requires link and context to be in the same element, not the same parent element. Can we add that to Understanding?

mraccess77 commented 3 years ago

I don't understand why a span or other element as a parent would prevent this from being met if the link is still contained within a list items or paragraph. The test of this criterion was if a screen reader user could read it without moving focus using screen reader commands to read the current list item and paragraph. The programmatic context is still available whether it is a parent or grandparent element. This is fortified by the allowance of the associated table header cell to be used to meet this requirement - that indicates the link doesn't even need to be in the same subtree.

We do need to agree on what a paragraph is - screen readers seem to treat divs like paragraphs in terms of the read paragraph command - so does this really need to be a p element versus a div?

patrickhlauke commented 3 years ago

The test of this criterion was if a screen reader user could read it without moving focus using screen reader commands to read the current list item and paragraph

I'd say part of the problem is also that there's, to me, a distinction between what can be "programmatically determined" and what (past and current) screen readers actually expose easily/without moving focus. The latter is a vague subset of the former, as there are a lot of things that can be (with the right approach) be programmatically determined. There's a lot more that's technically feasible to unambiguously determine context, just that AT don't expose it.

giacomo-petri commented 2 years ago

Hello everyone,

the lack of methodology to determine what "programmatically determined link context" means (in practice), in combination with

make this topic relevant in my opinion.

First of all would be great having a definition of paragraph, to clarify that paragraph != p (1.4.8, 1.4.12, 2.4.4 and multiple WCAG definitions). Second, would be great having a clear definition of "programmatically determined context". As we have rules do determine and calculate how the accessible name is computated depending on the element, similarly would be very helpful to determine how to calculate context.

Interesting the ACT-Rules definition Programmatically Determined Link Context with a link to the Block container definition.