SC-1.3.1 - paragraphs not semantically coded

[mmiron-HC]

Hi there, I have a question about the semantic coding of paragraph text. On one of our projects, the development team has implemented all paragraph content within <div> elements rather than using appropriate <p> tags.

We raised this as a failure under WCAG SC-1.3.1 Info and Relationship. The project team is pushing back, stating that the success criterion does not explicitly require that all text have a semantic role.

Could you clarify whether this constitute as a WCAG failure, even though the requirement for semantic paragraph markup is not explicitly stated? Specifically, does relying solely on <div> elements for paragraph text fail to convey the intended relationship or structure as required under SC-1.3.1?

Any guidance would be greatly appreciated.
Manon

[mraccess77]

My two cents. I think your code was rendered - but I assume you are talking about a div element or similar. Generally, I would not consider that a failure to have a paragraph content in a div rather than a paragraph unless there was some accessibility support issue or some other missing semantics.

[TestPartners]

Agreed. Although you're strictly correct that it's a non-conformance, you would have to be very, very picky to report it. I've never done so.

Your project team's statement that the success criterion does not explicitly require that all text have a semantic role is correct, but in my view it is not relevant. If the text is visually displayed as paragraphs, this should strictly be conveyed programmatically using <p> elements. Arguably, you would not need to use <p> elements for small pieces of text like skip links or "Back to top" links because they are not visually presented as paragraphs - these could be in <div> elements.

[fstrr]

@mmiron-HC If you edit your post to wrap the tags you're talking about in backticks, they'll display properly. At the moment, they're being treated as HTML, which is why they're not showing and you've got some odd line breaks. :)

[scottaohara]

i've edited the original post to fix the instances of HTML elements that weren't rendering due to lack of being identified as code.

but to expand on what others have said - in HTML a paragraph is not defined just as a p element.

i'll stop my comment there though, as i wrote a blog post on this exact subject

[TestPartners]

Scott, I just read your blog and the HTML specification, and it's not what I was expecting. Your blog says "Not every paragraph needs to be a <p> element with an implicit paragraph role", which begs the question "when do paragraphs need to be <p> elements?" If the answer is never, why does the <p> element even exist? BTW, there are loads of typos in your blog.

[mbgower]

A <div> has no semantic meaning, so if an implementer has used those to contain what is clearly paragraphs of information, I think they are certainly at risk of a failure of 1.3.1 and possible at some point a failure of 2.4.4 Link purpose.

It is much safer to put paragraphs of text inside <p> elements. As noted previously, where the chunk of text is not a paragraph, then they shouldn't be marked up as paragraphs either. I agree with the overall view that this is unlikely to be a signficant issue, but why risk an unintended negative effect with users?

Some side effects of using divs instead could be:

1. ATs unable to navigate by paragraph (including skim reading).
2. Links that are contained within a <div> are not actually semantically linked to anything meaningful. A link inside a paragraph can meet 2.4.4 as a sufficient technique.

[TestPartners]

A <div> has no semantic meaning, so if an implementer has used those to contain what is clearly paragraphs of information, I think they are certainly at risk of a failure of 1.3.1 and likely at some point a failure of 2.4.4 Link purpose.

While I think this should be the case, it's not what the HTML5 specification says. It explicitly says that many elements can be paragraphs, including <span> and <div>.

[GreggVan]

While I think this should be the case, it's not what the HTML5 specification says. It explicitly says that many elements can be paragraphs, including <span> and <div>.

oh my. really?
what happened to semantic markup?

[mbgower]

While I think this should be the case, it's not what the HTML5 specification says. It explicitly says that many elements can be paragraphs, including <span> and <div>.

@TestPartners can you provide a citation on this, please.

[MG Update: A bunch of comments happened in a short period of time, and I missed Scott's prior post. Sorry for the churn.]

[TestPartners]

While I think this should be the case, it's not what the HTML5 specification says. It explicitly says that many elements can be paragraphs, including <span> and <div>.

@TestPartners can you provide a citation on this, please.

It's all explained in the links Adrian provided to his blog and the HTML5 specification. The latter states "The term 'paragraph' as defined in this section is used for more than just the definition of the <p> element. ... The <p> element is merely one of several ways of marking up a paragraph." This statement is followed by several examples.

[scottaohara]

Scott, I just read your blog and the HTML specification, and it's not what I was expecting.

And that's exactly why I wrote the blog post / link to the HTML spec. For anyone who is unaware of what is/isn't a "paragraph"

Your blog says "Not every paragraph needs to be a <p> element with an implicit paragraph role", which begs the question "when do paragraphs need to be <p> elements?"

I did talk about that in my post. I went and updated that section a bit after reading the comments here to try and be a bit clearer. But to be honest I didn't get overly explicit because I wanted people to actually go read the HTML spec and look at the examples there.

BTW, there are loads of typos in your blog.

yeah that happens. You also have a typo in your last comment. You spelled my name "Adrian" :). But, I did go correct the 5 typos so as to not distract people from the point of the post, if they read it.

As per Gregg's comment about "what happened to semantic markup?" ... well, look at the examples of "semantic" paragraphs that HTML outlines for the p element. Examples that have been in HTML since it was actually called HTML5 and WCAG 2.0 was being published.

The p element should not be used when a more specific element is more appropriate.

The following example is technically correct:

<section>
<!-- ... -->
<p>Last modified: 2001-04-23</p>
<p>Author: fred@example.com</p>
</section>

However, it would be better marked-up as:

<section>
<!-- ... -->
<footer>Last modified: 2001-04-23</footer>
<address>Author: fred@example.com</address>
</section>

Or:

<section>
<!-- ... -->
<footer>
 <p>Last modified: 2001-04-23</p>
 <address>Author: fred@example.com</address>
</footer>
</section>

There's semantic HTML, and then there's HTML semantics that are actually important for accessibility. Let's make sure WCAG 3 understands this....

But to close out this comment, a fun fact I called out in my blog post that I'll reiterate / expand on here... Using NVDA and navigating by paragraphs (using the P key), guess which of the following "paragraphs" would be navigated to. Hint: read the text of the examples. They give away the answer :)

<div>I'm a paragraph!</div>

<p>i'm a <i>real</i> paragraph though.... or am i</p>

<span>I'm an implicit paragraph. And I have been defined as such for at least two decades.</span>

As I mentioned - NVDA has their own fun heuristics going on where even if you use a p element, it can be completely ignored as a "paragraph" if it lacks, for instance, a period. Programmatically exposed as a paragraph or not be damned. This is not suggesting that NVDA is doing anything wrong here, or that anyone should fail 1.3.1 if using a p element without punctuation.

I think I'm done talking about this again, for now.

[mbgower]

This seems like a continuation of a discussion that took place at TPAC -- and issues like #4655. Here's the pattern and problem, IMO:

1. HTML is created which aspires to designate correct semantic and non-semantic/generic elements.
2. An author, either not great at basic English or the proper use of HTML (I'll more likely fall in the second group), begins improperly using elements so that syntactical constructs are not reflected in the semantics of the code (or vice versa).
3. HTML introduces new features or reinforces quirks that potentially decouple linguistic syntax and semantics from code elements.
4. The spec is helped along on this journey by how user agents over time decide to interpret/present the HTML.
5. The screen reader manufacturers (and other ATs) begin to create algorithms to better predict semantic structure to compensate for the above stew.
6. When 1.3.1 issues are raised, defenders point to step 5 to show that it's all okay, OR the opposite -- that even though something is coded correctly, it's not surfaced by screen readers, and therefore is somehow insufficient (e.g., use of em and strong).

The above list is a great example of this. Semantically (in the linguistic sense), that preamble and list is one paragraph. But if you code that as <p>Preamble:<ol><li></li></ol></p> it will be considered insufficient/incorrect, and likely morphed by the user agent to be <p></p><ol>... which linguistically is silly.

People can shove text on the screen however they like, of course. If we divorce this from a web presentation, you can type a bunch of sentence fragments on a piece of paper and separate them with white space. But linguistically those are not paragraphs; they're not even sentences. They would likely be described as free verse, and a very good argument can be made that when we recreate that on a web page, each stanza/section is best constructed as div elements containing br elements.

Obviously people can write in sentence fragments meaningfully. There are examples of famous authors doing it very successfully. Despite starting with some sentence fragments, I'm still going to shove the first paragraph of Dicken's Bleak House inside a p tag. So we have to attempt to make the code reflect the linguistic intent.

But we are doing no one favours when we begin to water down the benefits of 1.3.1 for current and future assistive technologies. Where text is clearly forming a paragraph, it should be in a paragraph element. Where text is clearly not a paragraph, it shouldn't be in a paragraph element. The more clearly there is a failure to match the linguistic reality with the code reality, the more likely I would be to fail it under 1.3.1.

As an action, I'm going to open up an issue with the html spec about their paragraph guidance.

[scottaohara]

i don't think it's watering down 1.3.1 to acknowledge reality.

people should use the p element whenever it makes sense to do so.

people should not fail a page for 1.3.1 if someone doesn't use a p element, in a situation where doing so would just be extra markup that doesn't actually change the user experience / based on an inaccurate understanding of how "paragraph" is defined in HTML - and thus the basis for how screen readers interpret "paragraphs".