WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Steve Faulkner
Date: Feb 11, 2018 5:43AM

>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.

agreed, that's why we modified the the semantics for header/footer in
sections/articles in the HTML Accessibility mappings spec so they have a
generic group role that is not conveyed by default in the aural UI.

--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

On 11 February 2018 at 11:50, Mallory < <EMAIL REMOVED> > wrote:

> 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:webaim-forum-bounces@
> list.webaim.org]
> > >> >> > >> 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.
> > > > > > > > > > > > >