WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Birkir R. Gunnarsson
Date: Feb 11, 2018 8:49AM

I'm on board with that idea. Having a shortcut that navigates to divs
never made sense to me, maybe it did a long time ago when one webpage
had less than 10 million divs.



On 2/11/18, Steve Faulkner < <EMAIL REMOVED> > wrote:
>>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.
>> > >> > >> > >> > >> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.