Comments

Anonymous’s picture

Status: Needs review » Needs work

+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:

<div id="main-menu" class="navigation" role="navigation">
<h1>Main Menu</h1>
(optional) <h2>Menu Block Name</h2>
<ul>
<li>Menu Item 1</li>
<li>Menu Item 2</li>
</ul>
</div>

<div id="secondary-menu" class="navigation" role="navigation">
<h1>Secondary Menu</h1>
(optional) <h2>Menu Block Name</h2>
<ul>
<li>Menu Item 1</li>
<li>Menu Item 2</li>
</ul>
</div>

<div id="content" class="column" role="main">
<h1>Article</h1> (or in case of a category <h1>Category/ Listing</h1> for example)
<h2>Title of Article/ Category/ Listing</h2>
<ul>
<li>Menu Item 1</li>
<li>Menu Item 2</li>
</ul>
</div>

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:

<div id="main-menu" class="navigation" role="navigation">

Could become this:

<div id="main-menu" role="navigation">

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

mgifford’s picture

Lots 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

mgifford’s picture

Status: Needs work » Needs review

bartik-aria-landmark-roles.patch queued for re-testing.

mgifford’s picture

Issue tags: +a11ySprint

Just like Seven I think.

mgifford’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -a11ySprint

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

webchick’s picture

Status: Reviewed & tested by the community » Needs review

Sorry, Mike, you can't RTBC your own patch. Can someone else from the a11y team provide review?

mgifford’s picture

Will do.. Thanks for enforcing good process..

ao5357’s picture

StatusFileSize
new1.58 KB

I'm not sure the banner role is appropriate for $tabs for two reasons per the ARIA spec:

  1. The tabs are navigation for page-specific content rather than site-specific content
  2. A banner role should only be used once per page, and is already used for the header

@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?

cb’s picture

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

mjohnq3’s picture

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

mgifford’s picture

Status: Needs review » Reviewed & tested by the community
StatusFileSize
new390.83 KB

Good enhancement. I've attached a screenshot and am marking this RTBC. Thanks everyone.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed to 8.x. Thanks!

mjohnq3’s picture

Status: Fixed » Needs review
StatusFileSize
new509 bytes

Reopening.

Per the W3C's Using ARIA in HTML, it's recommended to use the contentinfo ARIA Landmark Role for the main Footer on a page.

Status: Needs review » Needs work
Issue tags: -Accessibility, -aria

The last submitted patch, bartik-aria-landmark-roles-footer.patch, failed testing.

mjohnq3’s picture

Status: Needs work » Needs review
Issue tags: +Accessibility, +aria
mgifford’s picture

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

mgifford’s picture

Status: Needs review » Reviewed & tested by the community
StatusFileSize
new120.87 KB

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

catch’s picture

Status: Reviewed & tested by the community » Fixed

Committed/pushed to 8.x, thanks!

mgifford’s picture

Status: Fixed » Active

This 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 contentinfo role?

 <div id="footer-wrapper"><footer class="section" role="contentinfo">

    <?php if ($page['footer_firstcolumn'] || $page['footer_secondcolumn'] || $page['footer_thirdcolumn'] || $page['footer_fourthcolumn']): ?>
      <div id="footer-columns" class="clearfix">
        <?php print render($page['footer_firstcolumn']); ?>
        <?php print render($page['footer_secondcolumn']); ?>
        <?php print render($page['footer_thirdcolumn']); ?>
        <?php print render($page['footer_fourthcolumn']); ?>
      </div> <!-- /#footer-columns -->
    <?php endif; ?>

    <?php if ($page['footer']): ?>
      <div id="footer" role="contentinfo" class="clearfix">
        <?php print render($page['footer']); ?>
      </div> <!-- /#footer -->
    <?php endif; ?>

  </footer></div> <!-- /.section, /#footer-wrapper -->

Thanks Sarah for highlighting this in your DrupalCon talk - http://sydney2013.drupal.org/creating-dynamic-and-accessible-content-dru... - very useful.

mjohnq3’s picture

I'd say footer, not footer-wrapper, should be the element where the contentinfo role is located as that area typically contains "copyrights and links to privacy statements".

The footer id is used several places in Bartik's CSS and is specific to the footer region.

mgifford’s picture

So for clarification, you'd suggest keeping <div id="footer" role="contentinfo" class="clearfix">

mjohnq3’s picture

Umm, Yes.

mgifford’s picture

Status: Active » Needs review
StatusFileSize
new646 bytes

Ok, it's fixed up here.

mgifford’s picture

rootwork’s picture

Status: Needs review » Reviewed & tested by the community

Pretty minimal patch so not sure if you need confirmation of this, but patch applied and it looks good.

dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 8.x. Thanks.

rootwork’s picture

Issue tags: +SprintWeekend2013

Just tagging this as work done during the global sprint.

Automatically closed -- issue fixed for 2 weeks with no activity.