Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of <article> tag inconsistent with definition in HTML spec #467

Open
handshape opened this issue Aug 18, 2022 · 2 comments
Open

Use of <article> tag inconsistent with definition in HTML spec #467

handshape opened this issue Aug 18, 2022 · 2 comments

Comments

@handshape
Copy link

handshape commented Aug 18, 2022

Hi there -- the Liebling template uses an <article> tag as the top-level element for each article card. While it's understandable how this would seem reasonable, it's actually not okay under the spec.

The <article> tag is intended to contain a self-contained, independantly-distributable composition. The cards on the list pages don't satisfy this condition. In particular, the use of the <article> element creates downstream accessibility issues for folks that use screen-readers.

@eddiesigner
Copy link
Owner

Hi,

I understand your point but actually the spec also suggest that the <article> tag can be used in situations like this:

A given document can have multiple articles in it; for example, on a blog that shows the text of each article one after another as the reader scrolls, each post would be contained in an <article> element, possibly with one or more <section>s within.

You can see some examples in the MDN docs: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/article

I used an accessibility testing tool and there is no issue by using articles in this way, I would say that this is even the way to do it.

I appreciate your concern but I think no changes are needed in this case.

@handshape
Copy link
Author

The accessibility of the template is quite good, barring this one issue. I would encourage you to try an actual screen-reader rather than an accessibility testing tool in order to observe the impact. (ChromeVox is free, and behaves quite closely to commercial screen-readers)

The "self contained" and "independently redistributable" semantic requirements are actually pretty important. You'll observe that the screen reader will treat each <article> as a complete article as the user walks the accessibility "focus" forward, and the additional controls and labels therein are treated as though they're the text of the article and read in their entirety rather than being presented as separate controls.

The examples cited in the MDN docs are for blogs where the actual articles are peers or descendants on a single long page, rather than a list of article links.

I'll be working with impacted users next week to get their opinions -- I'll be A/B testing versions that treat each card as either plain-old <div> elements at the top level or as an unordered list. Depending on which of the two works best for them, I'll submit a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants