Decide how to include WAI-ARIA landmark roles

+1 for the idea; I'm not sure what themers would like best. As a developer, I see the appeal of defining roles in the theme.info file.

Would we need to allow the theme.info roles to be over-ridden by the actual blocks or content that end up in those regions? For example, a role="navigation" region might be used in a special situation by a block that needs role="search" or "navigation". For that reason, it seems better to have all this applied in code rather than hard-coding roles into a page.tpl.php file.

I think we'll find some good leadership & best practices from themes that have taken the #d7ax pledge.

By and large, regions should not have roles. Regions are dumb containers - they have no idea what they contain. Its the content in the region that should get a role, i.e. roles should be applied to block and entity wrappers etc.

I'm actually being so bold as to changing the title, because really, adding roles to regions is a no go because it makes way to many assumptions about what a region might contain (is it a menu, or an article, or a form - regions don't know and don't care).

Not even role="main" belongs on a region, it belongs on the main content block.

There are two ways to add roles, both are currently available to themers right now:

1. $attributes variable - we can push new attributes via preprocess functions to any template.
2. hard code them in template files.

I would push hard for us picking one and being very consistent with it - my vote goes to $attributes.

I don't know of one as yet Everett, although the next versions of my D7 themes will do this, I've just lacked time to implement it.

You are right, core can push out these attributes, and themes could remove them.

There are a couple of exceptions I can think of that can't be done with the current use of attributes - namely role="banner", which applies to the site header, and role="contentinfo", which applies to the site footer - both of which could either be hard coded or we could add new attribute variables just for these exceptions (there could be others, I can't recall right now).

By and large though modules/core could add these attributes. For example menu module could add "role="navigation" to menu blocks and the search module could add role="search" to search forms/blocks etc.

I cant think of a situation where a menu block is not navigation.

I don't think we should have a front facing UI specifically for roles, that would likely confuse and overwhelm the majority of users. We could do a reasonable job of mapping roles to HTML5 elements if we have a way to select wrappers in D8 for user created blocks - so that is a possibility.

The way I see it working is that we can do a pretty good job with automation, meaning using attributes variables, and layer something on top of this such as mapping roles to HTML5 wrappers - ideas are needed here.

Changing title, I think its really a no brainer for us to use roles, so first we need to figure out how we're going to include roles, then work through the actual implementation of each role.

Lets make this issue about how we include them - so far we have proposed using $attributes or adding them directly into templates (maybe a combination of those two), also maybe there is some other way I have not thought of?

I'd think that we could start pretty easily with Genesis as an example and then move from there.

Is there a proposed approach to moving Bartik to HTML5? We're dropping Garland & Seven at the least needs to be renamed.

Do we want to add ARIA to Stark?

Everett, great work with - http://drupal.org/node/1179668 - my only suggestion is a few links to external resources to examine ways of implementing it in other contexts.

subscribing

<input title="Enter the terms you wish to search for." placeholder="Search" required="" role="Search" type="search" id="edit-search-block-form--2" name="search_block_form" value="" size="15" maxlength="128" class="form-text form-search">

This is what I added to my Genesis subtheme to add the role & also a placeholder for this block:

function MY_SUBTHEME_form_alter(&$form, &$form_state, $form_id) {
  switch ($form_id) {
    case 'search_block_form':
      // HTML5 placeholder attribute
      $form['search_block_form']['#attributes']['placeholder'] = t('Search');
      $form['search_block_form']['#attributes']['required'] = '';
      $form['actions']['submit']['#type'] = 'submit';
      $form['actions']['submit']['#value'] = t('Go');
      $form['search_block_form']['#attributes']['role'] = t('Search');
      break;
  }
}

As far as Genesis, I like practical examples that we can execute now, where possible. Totally understand that the end goal is core.

On your post, I was looking for links mostly. I like to look at examples where code has been implemented to get a sense of where I might find the best way to capture the role for whatever widget you're trying to best describe.

Drat. How about:

      <form action="/blog" method="post" id="search-block-form" accept-charset="UTF-8"><div><div class="container-inline" role="search"> 
      <h2 class="element-invisible">Search form</h2> 
    <div class="form-item form-type-searchfield form-item-search-block-form"> 
  <label class="element-invisible" for="edit-search-block-form--2">Search </label> 
 <input title="Enter the terms you wish to search for." placeholder="Search" required="" type="search" id="edit-search-block-form--2" name="search_block_form" value="" size="15" maxlength="128" class="form-text form-search" /> 
</div> 
<div class="form-actions form-wrapper" id="edit-actions"><input type="submit" id="edit-submit" name="op" value="Go" class="form-submit" /></div><input type="hidden" name="form_build_id" value="form-h-rNzTBHQbtFGVBIetSn1e45o6Frux9-fTtXYlKpC98" /> 
<input type="hidden" name="form_token" value="6_SykYAhlZ7JlA2uRhSvNQ5_nNZLe0xuKLueRiEUcEk" /> 
<input type="hidden" name="form_id" value="search_block_form" /> 
</div> 
</div></form> 

via customizing search-block-form.tpl.php :

<div class="container-inline" role="search">
  <?php if (empty($variables['form']['#block']->subject)) : ?>
    <h2 class="element-invisible"><?php print t('Search form'); ?></h2>
  <?php endif; ?>
  <?php print $search_form; ?>
</div>

form_alter could probably work too, to apply it to the form element, but otherwise.....

What we're looking for Mike is a very consistent way to apply roles - afaict we can do this with attributes arrays in most cases - so block and entity HTML wrappers, and special case the roles such as banner and contentinfo (such as create new attributes variables for our page header and footer) seems to make sense, we can place the role on the very outer wrapper in each case.

One thought: What happens when a non WAI-ARIA theme is used if we include WAI-ARIA support into core? Will we then end up with a semi-WAI-ARIA site that perhaps could be worse than a non-WAI-ARIA site?

I'm not very familiar with WAI-ARIA but looking at how Microformats has sometimes been implemented by frameworks they have often been broken by third party themes not being aware of their existence or of how to use them - thus ending up with an unusable and/or misleading the Microformat markup. No Microformats markup would in those cases have been better than a broken misleading one.

If the case could be the same with WAI-ARIA in Drupal then I think it should be an opt-in for themes in their info file so that themes not opting in won't have a broken WAI-ARIA implementation.

Makes sense?

Thanks Jeff. Definitely good to seek a consistent way to implement this.

@voxpelli - It might matter to validators that haven't kept up, but I don't see how having a few extra attributes will matter to users. If anything someone who uses AT will get a better experience. I certainly haven't heard people say that it's all or nothing with ARIA.

What really speaks against utilizing #attributes? It seems very sensible that the module declaring the block would know if and which role is to be applied.

I attached a sample patch for search module, which I tested locally.

@#21, #22: A possible solution would be to have a installation or theme configuration boolean called use_aria (or whatever). Then drupal_attributes() can be patched so that it would remove any ARIA attributes if use_aris is false. I came up with this idea in #405360: Use aria-describedby to link form elements with form element descriptions#38.

The HTML5 initiative is planning on having a theme in contrib that will fully support XHTML, so that theme could include overrides that remove roles.

Alternatively we could have an ARIA roles module, that is enabled by default?

The reason I find this easier for developers to implement e.g. in hook_block_view() rather than in e.g. template_preprocess_block() is because the specific role chosen has an intimate relationship with the data it surrounds, so as a developer it makes sense to specify the role right where the data is specified rather than in a theming hook which conceptually has (more or less) nothing to do with the actual data.

Lets try to think though what our broader requirements are, that should lead us closer to an implementation - this is what I am thinking we need:

1. Roles are ON by default
2. They can be overridden easily (like classes)
3. They can be turned off easily (like RDFa)

This is what lead to me to the module idea and doing it in the theme layer - easy to override and you can just turn it off. I'm not pushing real hard for this, its just an idea that I can see would work (maybe you think differently).

Well my approach would allow to override and remove the roles from e.g. template_preprocess_block(), so 2. would be fine.
I don't know if this is comparable to RDF module. The markup that is added is relatively leightweight; if I get it correctly maybe something like 10 attributes on a page would be realistic. That's why I'm not sure it makes sense to put this into a module.

Sure, it would be like 10 on an average page, what I am thinking more of is XHTML validation, if site builders are locked into that as a client requirement and don't know anything about preprocess functions etc. I would assume the proposed "legacy theme" is going to have to remove these so it will be done there, maybe that's enough.

I totally agree.

Just a note that #25 is correct in that using the patch in #24 the role is applied to the fom itself not to the container. That should doable, though.

Just wanted to point people to #1302482: Ensure render arrays properly handle #attributes and add them there instead of preprocess hooks, which would allow for exactly what was discussed here above. That doesn't mean we have to do it that way, but I still think #29 is a killer argument (hehe :)).

Adding tag for WAI-ARIA.