Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
Bartik theme
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
3 Oct 2012 at 20:59 UTC
Updated:
29 Jul 2014 at 21:15 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
Anonymous (not verified) commented+1
Should we add?
1. a role="complementary" for blocks? Unless a block is a menu used for navigation?
We could use PHP to check if a block was created by the menu module or not in order to differentiate if it is a menu block, complementary, form, banner or other content. If it doesn't exist already, there would have to be some kind of documentation/ work flow in order for module authors to be able to easily work this into their module.
2. role="form" for comment and contact forms?
Related Projects
We could also possibly work together and learn with the following themes:
As well as several others:
http://drupal.org/search/apachesolr_multisitesearch/aria?filters=drupal_...
I found these articles to be helpful in explaining Aria roles:
Converge issues?
Maybe we can converge the Seven and Bartik Issues and make them into 'Add Aria Roles to Core Themes'?
Inventory needed
It could also be smart to make an inventory of uses and their roles, if any.
Easier navigation?
This issue could tie in with the html5, and being able to add headers to each region fo easier navigation. So for example something like the following pseudocode:
I'd be willing to spend some time on this. I could add a few hours per month. We could sit down as a group on certain days, and meet up over IRC or something and work out the details and the code. It may be advisable to get some feedback from a core maintainer before we start, to make sure we're heading in the right direction. As well as make it easier to tie in different resources. This so that we have a encompassing way forward, or we can make it into a case study for example and proceed from there. It would be nice though to have community support, a roadmap, and a procedure working towards a succesful solution on this.
Edit:
Optimizing the HTML
According to the article Styling Webpages With ARIA’s ‘Landmark Roles’ it should be possible to style through the aria roles. In which case:
Could become this:
Tidying things up a bit, and removing redundancy. There would have to be full browser support for this though. As soon as I find more on information on that, I'll post it here. If you have information on this please feel free to post it. :-)
Comment #2
mgiffordLots of good ideas @design_dolphin - Thanks!
1) This needs to be tested, but think we got it into Core here #1183042: Regression: Add WAI-ARIA roles to Core blocks
I've been trying to keep issues organized under the tag aria
2) I like the idea of role="form" but think that might go better with the Forms API. It should be applied to all forms, right? In which case we need to set up a new issue.
Absolutely good to to look at, work on and share with others. @Jeff's AdaptiveTheme is a great starting point as is @John's Zen. Not sure which is using ARIA the best right now. Also modules like:
http://drupal.org/project/accessible
https://drupal.org/project/block_aria_landmark_roles
Good links for sure. Education is important & authoritative references certainly help.
Meta Issues are useful but can also bog down the process. Where we can it's good to reduce the load on the core maintainers. That being said, we want approval from folks focusing on Bartik & Seven. I'm not too worried about Stark, but we will be getting a new Core theme too i think (and that will need some review I think).
I like inventories. I also think I need a bit more explanation about what you've included in the navigational text above.
I'm totally happy to hear that you can put in some sustained time into this. Lots of work to do for sure. Main thing is to keep working on it as it can take a while to get things into Core.
I'm all for removing redundancy, but it's going to take some testing & screen shots to see how it works. I also think they were looking at ID's & not classes. Would have to talk to more CSS folks to see what type of a change that might make.
There's a Skype group where we have regular chats. They are also announced on http://groups.drupal.org/accessibility
Comment #3
mgiffordbartik-aria-landmark-roles.patch queued for re-testing.
Comment #4
mgiffordJust like Seven I think.
Comment #5
mgiffordThis is a simple addition of ARIA. There are no visual changes.
@no_longer_active_13 (previously @design_dolphin) added some suggestions but then left the community.
I think there are more places to add ARIA landmarks roles for this theme, but this is a basic implementation that's good to go.
Comment #6
webchickSorry, Mike, you can't RTBC your own patch. Can someone else from the a11y team provide review?
Comment #7
mgiffordWill do.. Thanks for enforcing good process..
Comment #8
ao5357 commentedI'm not sure the banner role is appropriate for $tabs for two reasons per the ARIA spec:
@mgifford is absolutely right that there are more places where ARIA roles would be appropriate, though this is decent coverage of landmark roles specifically.
Given #1077878: Add HTML5shiv to core, would it make sense to change the header div to a header element and various nav blocks to nav elements?
Comment #9
cbThat looks good and I agree with you on the roles, especially that there were two 'banner' roles.
But, I definitely don't think we should change the section divs to header/nav elements.
Comment #10
mjohnq3 commentedMuch of this has been done in: #1179764: Convert Bartik to HTML5. It's not yet complete, and for some reason it's not passing the testbot, but it's a start.
You can also review Responsive Bartik D7, which has ARIA landmark roles added to the page.tpl.php template where required.
Comment #11
mgiffordGood enhancement. I've attached a screenshot and am marking this RTBC. Thanks everyone.
Comment #12
webchickCommitted and pushed to 8.x. Thanks!
Comment #13
mjohnq3 commentedReopening.
Per the W3C's Using ARIA in HTML, it's recommended to use the
contentinfoARIA Landmark Role for the mainFooteron a page.Comment #15
mjohnq3 commented#13: bartik-aria-landmark-roles-footer.patch queued for re-testing.
Comment #16
mgiffordHard to argue with a "W3C Editor's Draft 29 December 2012"!
But partly it comes back to your patch here:
+ <footer id="footer" role="contentinfo" class="clearfix">We gotta get that issue fixed ASAP.
But yes, no concern with this. An important change.
Comment #17
mgiffordWe'll deal with the HTML5 issue elsewhere and just port this to that. I'll mark this RTBC now and we should be able to close this.
I just added a visualizations using juicy-studio's landmark mozilla accessibility plugin.
Comment #18
catchCommitted/pushed to 8.x, thanks!
Comment #19
mgiffordThis might need to be a new issue, but noticed that the ARIA role contentinfo is used twice in the Bartik theme. It's easy enough to just nix one, but then I started to wonder why we have both
<footer>& a<div id="footer">.The W3C specifies "Within any document or application, the author SHOULD mark no more than one element with the contentinfo role." This is for information about the parent document like "copyrights and links to privacy statements".
So for the block of HTML below, which should have the
contentinforole?Thanks Sarah for highlighting this in your DrupalCon talk - http://sydney2013.drupal.org/creating-dynamic-and-accessible-content-dru... - very useful.
Comment #20
mjohnq3 commentedI'd say
footer,not footer-wrapper, should be the element where thecontentinforole is located as that area typically contains "copyrights and links to privacy statements".The
footerid is used several places in Bartik's CSS and is specific to thefooterregion.Comment #21
mgiffordSo for clarification, you'd suggest keeping
<div id="footer" role="contentinfo" class="clearfix">Comment #22
mjohnq3 commentedUmm, Yes.
Comment #23
mgiffordOk, it's fixed up here.
Comment #24
mgifford#23: bartik-aria-landmark-contentinfo-23.patch queued for re-testing.
Comment #25
rootworkPretty minimal patch so not sure if you need confirmation of this, but patch applied and it looks good.
Comment #26
dries commentedCommitted to 8.x. Thanks.
Comment #27
rootworkJust tagging this as work done during the global sprint.