Maintainers versus Architects

@Brandon

I think what you are doing here, starting a conversation early, is the best way to start. Look at http://groups.drupal.org/butler for an example of some excellent ideas being generated for dealing with context better within Core code.

I think the basic workflow is:
1. Suggest areas for improvement (as you have done above).
2. Find others to collaborate with to refine the ideas into functional requirements.
3. Present those ideas to the community.
4. Begin to develop solutions against D8 head and hope others join in to finish / polish the solutions.

I do like that you started this conversation Brandon & think it would be great to have you added as a co-maintainer for D7. I think that's just a matter of adding a patch to the README.txt file isn't it. Everett, would it be useful for you to have one? If so we can get the ball rolling on this.

Everett, this is definitely a good insight, but I think it's too general & too specific for it. It's certainly good for things like Jeff's request to remove garland from core http://drupal.org/node/911054

But that's a much smaller issue (in many ways) than reviewing FAPI or looking at ARIA Support.

Jeff again has some good ideas for D8 in looking at the requirements for core themes. This post http://drupal.org/node/912458 spun into this wiki http://groups.drupal.org/node/94164 which I just edited to add WAI-ARIA support. This is a good way to both improve the improvement & build the community. It's also useful to start to define where/when/how this would all be done.

With ARIA there's going to need to be more interaction with the jquery folks too. Hopefully some things can be addressed upstream but whatever version of jquery D8 will be using. However, defining who we need to bring into the process and where the pain points are is going to be critical.

With FAPI I think we're at a good point to examine, document & look at how we want to address pain points as a community. Do we have a list of requirements for the API? Even the little work that we did to enhance the API last year was a huge effort. Partly because we were trying to inject a small change into a bigger process. Where do we start drafting our wish list & encouraging others to do the same? How do we take the D7 developers, fresh with their efforts (especially their failures) to change core & look forward to D8 to see if we can organize to get them addressed? How do we make it clear to new users of D7 that they can add to the list of issues they would want to see in D8 (and do so early) so that they might be built in (in 2 or so years time).

I added another form API accessibility issue for D8.

Programmatically associate form element and description with aria-describedby

I noticed #675446: Replace autocomplete.js with the jQuery UI Autocomplete plugin. I tested the plugin and noted in the issue that it doesn't appear to be any more accessible to screen-readers than what we have now. I am hoping that we can add this issue to those needing to be addressed for D8.

Ideally we can work with the jQuery UI team to improve the plugin so that we can begin to use it with Drupal, and so that others can use it as well. It is possible that we can either backport the changes to D7, or that we can implement the change for D7 using the Accessible Helper module, or a stand alone module.

I am also trying to make some ground on autocomplete accessibility for D7 in #515262: Autocomplete requires ARIA for screen-reader users

I have added more Drupal 8 issues.

#966396: Allow themes to specify WAI-ARIA landmark roles
#966432: Allow blocks to specify WAI-ARIA landmark roles