WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Explicit association with <header> required/recommended for <article>?

for

From: Mallory
Date: Feb 11, 2018 4:50AM

I think it could be useful to offer articles as navigable elements (but at the reader's discretion since some pages article up the articles with articles because it's like the new div for them). For <header> inside articles and sections... since I take it we're expected to put actual headings (<hx>) tags in the <header>s, I kinda don't see the point and AT really doing anything with them-- JAWS calling them all banners is harmful as it pollutes the banner role. Same for footers. When I use them in things like articles, it's for easier CSS styling and JS targeting. Semantics-wise it reminds me of email headers and bodies. Kinda like using aria-controls when aria-controls is pointing to someone who is display: none-- it apparently does nothing useful when the pointed-to thing is display: none, but it looks cute in the code and is nice as a JS hook.

cheers,
Mallory

On Tue, Feb 6, 2018, at 10:12 PM, Birkir R. Gunnarsson wrote:
> The spec guidance for how to treat <article> and <header> elements and
> the article role is confusing.
> If you look at the ARIA in HTML5 table entry for the <article> and
> <header> elements
> http://www.w3.org/TR/html-aria/
> you see that the <header> element, when child of a <section> or
> <article> element is not a banner landmark and should not be treated
> as such (there is a discussion on this over on GitHub, I can dig up
> the link and post it here later)
> But how should assistive technologies treat a <header> element that is
> the child of an <article> element? There is no screen reader role for
> header, only heading or banner, both are different.
> Then there is the question of what to do with the article role itself
> (that the <article> element maps to).
> If you Google the ARIA 1.1 spec and locate the article role in section
> 5.4, you see that the article role is not supposed to be a landmark.
> Still the text says that assistive technologies should make usres
> aware of articles, though the specification does not say how.
>
>
> So we have two problems here.
> 1. What should assistive technologies do with the article role? Jaws
> lumps it in with landmarks rather than inventing a whole new way to
> navigate the page (sensible).
> NVDA ignores them, because there is no clear guidance on how to treat
> them (kind of makes sense)
> Voiceover offers a separate way to navigate by article (well, makes
> sort of sense).
>
> I can't fault any of the approaches to be honest.
>
> 2. What to do with the <header> tag?
> Jaws uses the banner role, because there is nothing else available at
> the moment, not necessarily good, I think it is a bad idea to be
> honest.
> But NVDA and Voiceover ignore this element, even if it technically has
> a semantic meaning. That is also bad, but how should it be
> communicated?
>
> I think this is a clear case of nobody has figured out whether this
> structure is useful to assistive technologies and how it can be made
> most useful.
> I would technically recommend putting a unique id on the header tag
> for each article and use aria-labelledby on the <article> tag to point
> to it.
> It doesn't hurt and for those assistive technologies that expose
> articles, they can now expose them with an accessible name.
>
>
>
> On 2/6/18, Mallory < <EMAIL REMOVED> > wrote:
> > Hi,
> > regarding this:
> >>However, it does list any <header> tags in the "Elements List" dialog under
> > "Landmarks" as "banner" (but only in IE).
> >
> > This is an IE bug :)
> >
> > JAWS also calls all headers "banners" in all browsers.
> >
> > The moving-by-article seems to be a JAWS thing as well.
> > https://github.com/FreedomScientific/VFO-standards-support/issues/35
> >
> > cheers,
> > Mallory
> >
> > On Mon, Feb 5, 2018, at 8:43 PM, Robert Fentress wrote:
> >> Also, starting at MacOS High Sierra, it is possible to navigate by article
> >> from the Web Rotor on VO (thanks to Scott O'Hara for the heads up on
> >> this). So, in that context, labeled articles is of benefit, as well.
> >>
> >> On Mon, Feb 5, 2018 at 1:35 PM, Robert Fentress < <EMAIL REMOVED> > wrote:
> >>
> >> > Interestingly, the "region" role is defined by ARIA 1.1 (
> >> > https://www.w3.org/TR/wai-aria-1.1/#region) as a subclass of landmark
> >> > (one not otherwise defined more specifically), so the fact that JAWS
> >> > "region" navigation includes things marked up with the <article> tag is
> >> > a
> >> > potential source of confusion. The <article> tag is defined in HTML5 as
> >> > "sectioning content" (https://www.w3.org/TR/html5/
> >> > sections.html#the-article-element) though, so I wonder if, maybe, it
> >> > would be better for JAWS to use that nomenclature. So, rather than
> >> > suggesting to users that they are navigating by *region*, JAWS should
> >> > indicate they are navigating by *section*, instead.
> >> >
> >> > Also, it appears as though NVDA doesn't do anything with the <article>
> >> > tag. However, it does list any <header> tags in the "Elements List"
> >> > dialog
> >> > under "Landmarks" as "banner" (but only in IE). This is interesting,
> >> > since
> >> > I aways saw a subtle difference between the <header> tag and the
> >> > "banner"
> >> > role, in that you can only have one element with the role "banner" per
> >> > page, but can have multiple <header> tags. So, all banners are
> >> > <header>s,
> >> > but not all <header>s are banners.
> >> >
> >> > Or so I thought. NVDA seems to see them as the same, based on this.
> >> >
> >> > Perhaps, I misinterpreted things, though, because <article> is defined
> >> > as
> >> > a subclass of "document". So maybe the rule isn't that there can't be
> >> > only
> >> > one banner per page, but, rather, only one banner per document?
> >> >
> >> > Maybe to benefit those NVDA users, you should use "aria-labelledby" on
> >> > both the <article> *and* the <header> tags, with both pointing to the id
> >> > of
> >> > the heading in the <header>. If you do that, those labelled headers are
> >> > listed as *Your heading goes here; banner* in the "Elements List"
> >> > dialog.
> >> >
> >> > On Mon, Feb 5, 2018 at 1:24 PM, Jonathan Cohn < <EMAIL REMOVED> >
> >> > wrote:
> >> >
> >> >> Also, with VoiceOver on Macintosh Articles can be blocks that need to
> >> >> be
> >> >> interacted with in at least "Group Navigation" mode. If they are not
> >> >> given
> >> >> a label than VoiceOver will just say "article".
> >> >> Thanks,
> >> >>
> >> >> Jonathan Cohn
> >> >>
> >> >> On Mon, Feb 5, 2018 at 12:32 PM Robert Fentress < <EMAIL REMOVED> > wrote:
> >> >>
> >> >> > So, checking in JAWS 18, CTRL+Insert+R brings up a list of regions on
> >> >> the
> >> >> > page. If you have labelled your region by pointing aria-labelledby
> >> >> > to
> >> >> the
> >> >> > id for the heading, then the article is listed with that name.
> >> >> Otherwise,
> >> >> > it just says article, even if you have a heading in the article.
> >> >> > Basically, it must be explicitly named.
> >> >> >
> >> >> > On Mon, Feb 5, 2018 at 11:53 AM, Robert Fentress < <EMAIL REMOVED> >
> >> >> > wrote:
> >> >> >
> >> >> > > Yeah, I guess you're right. A header could contain content other
> >> >> than a
> >> >> > > heading. So does the accessible name for the article automatically
> >> >> get
> >> >> > > populated with the highest heading level it contains then?
> >> >> > >
> >> >> > > My use case is if the user wants to have navigate amongst multiple
> >> >> > > articles on a page without diving into the contents of each. If
> >> >> > > there
> >> >> > are
> >> >> > > multiple nav elements on a page, you would need to label them to
> >> >> enable
> >> >> > the
> >> >> > > user to quickly jump to the one that is most relevant. In the same
> >> >> > sense,
> >> >> > > wouldn't you want to label articles? Actually, I don't even
> >> >> > > remember
> >> >> if
> >> >> > > any screen readers provide affordances for jumping between or
> >> >> > > listing
> >> >> > > articles, per se, but, if they did, I'd think this would be useful.
> >> >> > >
> >> >> > > On Mon, Feb 5, 2018 at 11:09 AM, < <EMAIL REMOVED> > wrote:
> >> >> > >
> >> >> > >> I think you mean heading, not header.
> >> >> > >>
> >> >> > >> Headers are repeating elements at the top of something, such as a
> >> >> page
> >> >> > >> header or table header.
> >> >> > >>
> >> >> > >> The Article tag's definition is that it designates a
> >> >> > >> self-contained
> >> >> > >> portion of a larger document. It is a grouping or container tag
> >> >> > >> that
> >> >> > >> encompasses, by definition, other tagged elements such as P and Hx
> >> >> tags.
> >> >> > >>
> >> >> > >> To me, the relationship is already explicit because the Hx tag is
> >> >> within
> >> >> > >> the Article tag.
> >> >> > >>
> >> >> > >> — — —
> >> >> > >> Bevi Chagnon, founder/CEO | <EMAIL REMOVED>
> >> >> > >> — — —
> >> >> > >> PubCom: Technologists for Accessible Design + Publishing
> >> >> > >> consulting ' training ' development ' design ' sec. 508 services
> >> >> > >> Upcoming classes at www.PubCom.com/classes
> >> >> > >> — — —
> >> >> > >>
> >> >> > >> -----Original Message-----
> >> >> > >> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ]
> >> >> > >> On
> >> >> > >> Behalf Of Robert Fentress
> >> >> > >> Sent: Monday, February 5, 2018 11:00 AM
> >> >> > >> To: WebAIM Discussion List < <EMAIL REMOVED> >
> >> >> > >> Subject: [WebAIM] Explicit association with <header>
> >> >> > required/recommended
> >> >> > >> for <article>?
> >> >> > >>
> >> >> > >> If content is marked up with the <article> tag and within that
> >> >> <article>
> >> >> > >> tag there is a <header> tag, is it required or recommended to make
> >> >> > >> an
> >> >> > >> explicit association between them using aria-labelledby attribute
> >> >> > >> or
> >> >> > would
> >> >> > >> that be redundant or too verbose? Thanks!
> >> >> > >>
> >> >> > >> --
> >> >> > >> Rob Fentress
> >> >> > >> Senior Accessibility Solutions Designer
> >> >> > >> Assistive Technologies at Virginia Tech
> >> >> > >> Electronic Business Card (vCard)
> >> >> > >> <http://search.vt.edu/search/person.vcf?person54847>
> >> >> > >> LinkedIn Profile
> >> >> > >> <https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>
> >> >> > >>
> >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >>
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > --
> >> >> > > Rob Fentress
> >> >> > > Senior Accessibility Solutions Designer
> >> >> > > Assistive Technologies at Virginia Tech
> >> >> > > Electronic Business Card (vCard)
> >> >> > > <http://search.vt.edu/search/person.vcf?person54847>
> >> >> > > LinkedIn Profile
> >> >> > > <https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>
> >> >> > >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Rob Fentress
> >> >> > Senior Accessibility Solutions Designer
> >> >> > Assistive Technologies at Virginia Tech
> >> >> > Electronic Business Card (vCard)
> >> >> > <http://search.vt.edu/search/person.vcf?person54847>
> >> >> > LinkedIn Profile
> >> >> > <https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>
> >> >> > > >> >> > > >> >> > > >> >> > > >> >> >
> >> >> > >> >> > >> >> > >> >> > >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Rob Fentress
> >> > Senior Accessibility Solutions Designer
> >> > Assistive Technologies at Virginia Tech
> >> > Electronic Business Card (vCard)
> >> > <http://search.vt.edu/search/person.vcf?person54847>
> >> > LinkedIn Profile
> >> > <https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>
> >> >
> >>
> >>
> >>
> >> --
> >> Rob Fentress
> >> Senior Accessibility Solutions Designer
> >> Assistive Technologies at Virginia Tech
> >> Electronic Business Card (vCard)
> >> <http://search.vt.edu/search/person.vcf?person54847>
> >> LinkedIn Profile
> >> <https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>
> >> > >> > >> > >> > > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > >