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

Bringing back ARIA roles? #1202

Open
samikeijonen opened this Issue Sep 11, 2017 · 22 comments

Comments

Projects
None yet
9 participants
@samikeijonen
Contributor

samikeijonen commented Sep 11, 2017

We removed ARIA roles in #1132. But WAI-ARIA 1.1 and HTML 5.1 specifications have been updated. This is the biggest change for ARIA roles:

<header> and <footer> elements will now only be exposed as header and footer, and banner and ContentInfo landmarks respectively, if these elements are direct descendants of the body tag, and therefore are scoped for the whole page.

In _s header and footer are not direct descendants of the body tag, they are inside #page wrapper.

My question is, should we bring back <header role="banner"> and <footer role="contentinfo">?

Here is more information about the ARIA roles subject.

@samikeijonen

This comment has been minimized.

Show comment
Hide comment
@samikeijonen

samikeijonen Sep 11, 2017

Contributor

It doesn't mention <main> but let's talk about that too.

Contributor

samikeijonen commented Sep 11, 2017

It doesn't mention <main> but let's talk about that too.

@davidakennedy

This comment has been minimized.

Show comment
Hide comment
@davidakennedy

davidakennedy Sep 13, 2017

Member

My feeling on this is: Yes. Kind of frustrating since we just removed them. 😄

We could also remove the wrapper container, but I have a felling that's useful in a lot of cases for designers and developers. Curious to hear what others think.

Member

davidakennedy commented Sep 13, 2017

My feeling on this is: Yes. Kind of frustrating since we just removed them. 😄

We could also remove the wrapper container, but I have a felling that's useful in a lot of cases for designers and developers. Curious to hear what others think.

@joedolson

This comment has been minimized.

Show comment
Hide comment
@joedolson

joedolson Sep 13, 2017

Should put header and footer back; there shouldn't be any need to do that with main.

I think that removing the wrapper container doesn't do anything to solve the problem - as soon as an author added one back in, the roles would be broken again.

joedolson commented Sep 13, 2017

Should put header and footer back; there shouldn't be any need to do that with main.

I think that removing the wrapper container doesn't do anything to solve the problem - as soon as an author added one back in, the roles would be broken again.

@philiparthurmoore

This comment has been minimized.

Show comment
Hide comment
@philiparthurmoore

philiparthurmoore Sep 15, 2017

Collaborator

FWIW I think the roles should be added back in, for precisely the reason that @joedolson mentioned. We cannot control how people use _s, but we can control how it's distributed, and doing it in a way that is developer-proof, as far as roles go, seems sensible.

Collaborator

philiparthurmoore commented Sep 15, 2017

FWIW I think the roles should be added back in, for precisely the reason that @joedolson mentioned. We cannot control how people use _s, but we can control how it's distributed, and doing it in a way that is developer-proof, as far as roles go, seems sensible.

@asuh

This comment has been minimized.

Show comment
Hide comment
@asuh

asuh Sep 18, 2017

From an outside voice and perspective, I vote that #page should be dropped instead of adding back aria roles to header and footer elements.

As of October 2017, after Windows 10 Fall Creators Update is released, all modern browsers support CSS Grid Layout. Together with mobile-first responsive design, the need for a global wrapper element is more of a past relic. Pages used to need global auto margins and fixed widths to be centered and this was good when we weren't really considering devices smaller than a laptop/desktop.

While we can't control how people use _s, promoting componentized wrapping instead of global wrapping allows more styling flexibility, follows the WAI-ARIA 1.1 and HTML 5.1 updates, and is following the change of what is becoming a modern best practice. More of the Alexa Top 500 have dropped global wrappers and I expect as more sites adopt CSS Grid Layout, this change will move faster and become a trend, not a fad.

Documentation for _s can educate what to do when someone needs to add a global wrapper.

asuh commented Sep 18, 2017

From an outside voice and perspective, I vote that #page should be dropped instead of adding back aria roles to header and footer elements.

As of October 2017, after Windows 10 Fall Creators Update is released, all modern browsers support CSS Grid Layout. Together with mobile-first responsive design, the need for a global wrapper element is more of a past relic. Pages used to need global auto margins and fixed widths to be centered and this was good when we weren't really considering devices smaller than a laptop/desktop.

While we can't control how people use _s, promoting componentized wrapping instead of global wrapping allows more styling flexibility, follows the WAI-ARIA 1.1 and HTML 5.1 updates, and is following the change of what is becoming a modern best practice. More of the Alexa Top 500 have dropped global wrappers and I expect as more sites adopt CSS Grid Layout, this change will move faster and become a trend, not a fad.

Documentation for _s can educate what to do when someone needs to add a global wrapper.

@samikeijonen

This comment has been minimized.

Show comment
Hide comment
@samikeijonen

samikeijonen Sep 19, 2017

Contributor

@asuh I have to say that I 100% agree with you. I'm definitely dropping #page from my own future themes.

I probably remove "extra" divs like <div id="content" class="site-content"> and <div id="primary" class="content-area"> also.

But I'm not sure is _s there yet. It's usually 1-2 years behind from latest and greatest, and for a reason (older browsers and 2 main versions of WP).

Contributor

samikeijonen commented Sep 19, 2017

@asuh I have to say that I 100% agree with you. I'm definitely dropping #page from my own future themes.

I probably remove "extra" divs like <div id="content" class="site-content"> and <div id="primary" class="content-area"> also.

But I'm not sure is _s there yet. It's usually 1-2 years behind from latest and greatest, and for a reason (older browsers and 2 main versions of WP).

@asuh

This comment has been minimized.

Show comment
Hide comment
@asuh

asuh Sep 19, 2017

I hope we reconsider our thinking about labeling CSS Grid Layout as the "latest and greatest" as we did with Flexbox or other features introduced with prefixes. Modern browsers are mostly evergreen, the iterations of new features like CSS Grid are developed inside browser feature flags so that when released it's mature and ready to go. Together with either Flexbox or messy IE10/11 prefixes, support for Grid goes back several browser versions.

Bringing this back to Aria, without the global wrapper, the only landmark element that really needs explicit Aria role, because of <=IE11, is <main> as described here: http://html5accessibility.com/

I would agree that _s doesn't need to be cutting edge for everything but I can't emphasize strongly enough that CSS Grid Layout should be the one exception. It's that important.

asuh commented Sep 19, 2017

I hope we reconsider our thinking about labeling CSS Grid Layout as the "latest and greatest" as we did with Flexbox or other features introduced with prefixes. Modern browsers are mostly evergreen, the iterations of new features like CSS Grid are developed inside browser feature flags so that when released it's mature and ready to go. Together with either Flexbox or messy IE10/11 prefixes, support for Grid goes back several browser versions.

Bringing this back to Aria, without the global wrapper, the only landmark element that really needs explicit Aria role, because of <=IE11, is <main> as described here: http://html5accessibility.com/

I would agree that _s doesn't need to be cutting edge for everything but I can't emphasize strongly enough that CSS Grid Layout should be the one exception. It's that important.

@philiparthurmoore

This comment has been minimized.

Show comment
Hide comment
@philiparthurmoore

philiparthurmoore Sep 21, 2017

Collaborator

I would agree that _s doesn't need to be cutting edge for everything but I can't emphasize strongly enough that CSS Grid Layout should be the one exception. It's that important.

I do not dispute the importance of CSS Grid Layout but I'd hardly consider it critical enough to distract from the core issue of this ticket, which is whether or not ARIA roles should be added back into header and footer elements.

Collaborator

philiparthurmoore commented Sep 21, 2017

I would agree that _s doesn't need to be cutting edge for everything but I can't emphasize strongly enough that CSS Grid Layout should be the one exception. It's that important.

I do not dispute the importance of CSS Grid Layout but I'd hardly consider it critical enough to distract from the core issue of this ticket, which is whether or not ARIA roles should be added back into header and footer elements.

@asuh

This comment has been minimized.

Show comment
Hide comment
@asuh

asuh Sep 21, 2017

whether or not ARIA roles should be added back into header and footer elements.

Understood. I was trying to create value to why the Aria roles don't need to be added back to header and footer and why the global wrapper should be dropped instead.

asuh commented Sep 21, 2017

whether or not ARIA roles should be added back into header and footer elements.

Understood. I was trying to create value to why the Aria roles don't need to be added back to header and footer and why the global wrapper should be dropped instead.

@samikeijonen

This comment has been minimized.

Show comment
Hide comment
@samikeijonen

samikeijonen Sep 22, 2017

Contributor

It seems that at the moment best approach is to add back the roles in header and footer. Any volunteers for PR, would be quick fix and huge amount of glory:)

Contributor

samikeijonen commented Sep 22, 2017

It seems that at the moment best approach is to add back the roles in header and footer. Any volunteers for PR, would be quick fix and huge amount of glory:)

@pattonwebz

This comment has been minimized.

Show comment
Hide comment
@pattonwebz

pattonwebz Oct 3, 2017

I made a PR adding back roles on header and footer. I will gladly accept glory for a quick fix lol

pattonwebz commented Oct 3, 2017

I made a PR adding back roles on header and footer. I will gladly accept glory for a quick fix lol

@samikeijonen

This comment has been minimized.

Show comment
Hide comment
@samikeijonen

samikeijonen Oct 3, 2017

Contributor

@pattonwebz Looks good to me!

@davidakennedy can approve or give feedback when he has time.

Contributor

samikeijonen commented Oct 3, 2017

@pattonwebz Looks good to me!

@davidakennedy can approve or give feedback when he has time.

@WraithKenny

This comment has been minimized.

Show comment
Hide comment
@WraithKenny

WraithKenny Oct 20, 2017

I think we are misreading the article here.

When it says "direct descendant," they aren't talking about body > header {} but rather in the context of landmark regions, i.e. body :not( article, section, main, nav, aside ) header {} (https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html). The wrapper div, being semanticless, should have no effect and not be a problem. Has anyone pulled FF57 to test whether this is an issue or not? (I haven't)

WraithKenny commented Oct 20, 2017

I think we are misreading the article here.

When it says "direct descendant," they aren't talking about body > header {} but rather in the context of landmark regions, i.e. body :not( article, section, main, nav, aside ) header {} (https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html). The wrapper div, being semanticless, should have no effect and not be a problem. Has anyone pulled FF57 to test whether this is an issue or not? (I haven't)

@samikeijonen

This comment has been minimized.

Show comment
Hide comment
@samikeijonen

samikeijonen Oct 20, 2017

Contributor

@WraithKenny That's a good point, and you might be right. Is it possible that you test it out?

Contributor

samikeijonen commented Oct 20, 2017

@WraithKenny That's a good point, and you might be right. Is it possible that you test it out?

@WraithKenny

This comment has been minimized.

Show comment
Hide comment
@WraithKenny

WraithKenny Oct 20, 2017

To be honest, I'm not exactly sure how or what to test here (sorry).

WraithKenny commented Oct 20, 2017

To be honest, I'm not exactly sure how or what to test here (sorry).

@samikeijonen

This comment has been minimized.

Show comment
Hide comment
@samikeijonen

samikeijonen Oct 20, 2017

Contributor
Contributor

samikeijonen commented Oct 20, 2017

@samikeijonen

This comment has been minimized.

Show comment
Hide comment
@samikeijonen

samikeijonen Oct 22, 2017

Contributor

I did some testing with Firefox 56.0.1 and 57.0b10. I was little surprised that there was no change at all how NVDA listed landmarks.

How I tested

  • Latest _s
  • NVDA version 2017.3
  • Firefox 56.0.1 and 57.0b10.

Test results

Both Firefox versions list landmarks like this with some test data.

Banner
-- Navigation

Main
-- Navigation

Complementary
--Search

Content info

I tested with Insert+F7 which list links, headings, and landmarks.

I also tested adding <section> around <header>. In this case banner is not listed but it happens in both Firefox versions. Based on article I assumed it would be listed in version 56 but not in version 57.

I could not test with Firefox Nightly because it kind of crashed NVDA in my computer.

Conclusion

I didn't notice any difference between 56.0.1 and 57.0b10. That would mean that we do not need to add ARIA roles back to header and footer.

But I would appreciate if someone could test also, and perhaps with Firefox Nightly also.

Contributor

samikeijonen commented Oct 22, 2017

I did some testing with Firefox 56.0.1 and 57.0b10. I was little surprised that there was no change at all how NVDA listed landmarks.

How I tested

  • Latest _s
  • NVDA version 2017.3
  • Firefox 56.0.1 and 57.0b10.

Test results

Both Firefox versions list landmarks like this with some test data.

Banner
-- Navigation

Main
-- Navigation

Complementary
--Search

Content info

I tested with Insert+F7 which list links, headings, and landmarks.

I also tested adding <section> around <header>. In this case banner is not listed but it happens in both Firefox versions. Based on article I assumed it would be listed in version 56 but not in version 57.

I could not test with Firefox Nightly because it kind of crashed NVDA in my computer.

Conclusion

I didn't notice any difference between 56.0.1 and 57.0b10. That would mean that we do not need to add ARIA roles back to header and footer.

But I would appreciate if someone could test also, and perhaps with Firefox Nightly also.

@grappler

This comment has been minimized.

Show comment
Hide comment
@grappler

grappler Oct 22, 2017

Collaborator

I tried to test it on my OSX but it seemed not to work with VoiceOver.

When using other tools to check the landmarks I could not see any difference between the Firefox 56 and 57.

As it would be only a specific issue related to Firefox I think we should wait before we till Firefox 57 is released as a stable version.

Collaborator

grappler commented Oct 22, 2017

I tried to test it on my OSX but it seemed not to work with VoiceOver.

When using other tools to check the landmarks I could not see any difference between the Firefox 56 and 57.

As it would be only a specific issue related to Firefox I think we should wait before we till Firefox 57 is released as a stable version.

@samikeijonen

This comment has been minimized.

Show comment
Hide comment
@samikeijonen

samikeijonen Oct 22, 2017

Contributor

This is getting interesting. In Voiceover Footer landmark is not listed without a role="contentinfo".

Screenshot in current _s:
no footer landmark in Voiceover

Screenshot with role="contentinfo" added:
footer landmark is listed in Voiceover

Seems to be a known bug but I had no idea about it. Fixing this bug might take a long time so I propose that we add at least <footer role="contentinfo"> back which was the original idea.

We can also wait for Firefox 57 so we can decide what to do with role="banner".

Contributor

samikeijonen commented Oct 22, 2017

This is getting interesting. In Voiceover Footer landmark is not listed without a role="contentinfo".

Screenshot in current _s:
no footer landmark in Voiceover

Screenshot with role="contentinfo" added:
footer landmark is listed in Voiceover

Seems to be a known bug but I had no idea about it. Fixing this bug might take a long time so I propose that we add at least <footer role="contentinfo"> back which was the original idea.

We can also wait for Firefox 57 so we can decide what to do with role="banner".

@samikeijonen

This comment has been minimized.

Show comment
Hide comment
Contributor

samikeijonen commented Oct 22, 2017

@samikeijonen

This comment has been minimized.

Show comment
Hide comment
@samikeijonen

samikeijonen Oct 23, 2017

Contributor

After short talk with a11y team, let's wait for FF57.

Maybe Voiceover bug goes away while waiting:)

Contributor

samikeijonen commented Oct 23, 2017

After short talk with a11y team, let's wait for FF57.

Maybe Voiceover bug goes away while waiting:)

@tyrann0us

This comment has been minimized.

Show comment
Hide comment
@tyrann0us

tyrann0us Jan 10, 2018

Firefox 57 has been released on November 14, 2017. Maybe we can refresh this issue?

tyrann0us commented Jan 10, 2018

Firefox 57 has been released on November 14, 2017. Maybe we can refresh this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment