WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible P Tag Usage


From: Jonathan Avila
Date: Mar 19, 2019 10:07AM

> Leaving text lying about in random <divs>… how is that not a straight-up violation of 1.3.1?

Duff, what information and relationship is missing that is not already programmatically available in text? I don't see it as a failure as someone using assistive technology has the same information available as someone with out assistive technology. A paragraph is a

Paragraph: a distinct section of a piece of writing, usually dealing with a single theme and indicated by a new line, indentation, or numbering.


-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Duff Johnson
Sent: Tuesday, March 19, 2019 12:03 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Accessible P Tag Usage

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Just a few observations… I wish I had more time for this fascinating question today...

> I agree with Patrick. This is a very low priority issue and I dont
> think one need to flag it as an violation as there are many ways such
> as inserting <br> tags to provide line breaks between the content.

Let's not confuse paragraphs with line-breaks! These are very different semantics.

> Please note not marking up headings, tables and list items impacts the
> screen reader users heavily hence these should be flagged as
> violations.

Let's also not just think in terms of screen readers! Users with ATs that highlight or zoom could well be impacted.

>> My personal opinion is that it is not a requirement for text to be contained
>> in at least a paragraph element. My thinking is that a paragraph element
>> conveys that its contents are all part of a paragraph--and that might not be
>> the information or relationship that the content author wants to convey.

I have to disagree - there's a clear obligation to provide semantics for each element of content.

It's not OK to leave some text flopping about in a <div> just because it's likely that some ATs will stumble over it correctly and in-context!

>> Then G115 says:
>> "... Using the appropriate semantic elements will make sure the
>> structure is available to the user agent. This involves explicitly
>> indicating the role that different units have in understanding the meaning
>> of the content. The nature of a piece of content as a paragraph, header,
>> emphasized text, table, etc. can all be indicated in this way. ..."
>> The strictest interpretation of these items is that it is required that
>> relationships in content are programmatically available, including content
>> "... such as a paragraph ...". Is this to be taken as saying text should, at
>> a minimum, programmatically be a <p> tag, unless there is a more appropriate
>> structural tag?

IMO, this is a correct interpretation.

>> We are aware that the sufficient techniques do not constitute required ways
>> of doing things, so we are hesitant to violate a customer based on the
>> suggested ways of meeting the criteria. However, when a failure condition
>> says content must be semantically appropriate, then a sufficient technique
>> lists paragraphs as appropriate semantics for text content, this implies
>> that if text content is not in a <p> or a more appropriate tag (like
>> headings, lists, etc.) it is not making the relationship/information about
>> the text "available to all users."

Completely correct.

>> On the flip side, what about including an empty <p> tag with no text
>> content, or only an image?

This is also invalid, although with an admittedly relatively low impact, since software can easily include heuristics to deal with empty elements.

>> Our concern arises from the fact that AXE and WAVE do not violate text
>> content which is not included in a <p> or other semantically appropriate
>> tag

Interesting - IMO, this should be addressed as a bug.

Leaving text lying about in random <divs>… how is that not a straight-up violation of 1.3.1?