NOTE: D8 Core gates are now posted.
Hi there, accessibility team! :)
Back at DrupalCon Chicago, Dries outlined a strategy for Drupal 8 involving a series of "gates" that would help ensure core code quality in a number of different categories: Documentation, Performance, Accessibility, Usability, and Testing. The purpose of gates is to define essentially a set of "checkboxes" which outline the most important aspects to each category, and does so in a way that is both not overwhelming to core developers (list of hoops to jump through is kept as small as possible) and also creates very little additional burden on the team in question (contains sample links to documentation/resources so developers/reviewers can help themselves).
Since we have already traditionally had requirements around documentation, it made sense to start there. Jennifer Hodgdon and some other folks from the documentation team have put together the Documentation gate, which is available at http://drupal.org/node/1203498. What we need is a similar table for each of the other gate areas. And that's where you come in! :D
So I'd love to kick off a brain-storm about what the top accessibility gates might be (please, no more than 5 if possible), with the goal being to fill out the following table. (This is a wiki page, so be bold!)
| Description | When is this needed? | Details | Resources |
|---|---|---|---|
| Automated Tests | Catch obvious stuff that is a known and easily identifiable problem | Run all proposed changes through an automated checking like the WAVE Toolbar to find barriers. If the changes affect color/shade combinations then run through A-Contrast to help identify problems. | Accessibility Handbook |
| New Patterns | The earlier a new pattern is checked for accessibility the easier it can be to corrected. If unsure, please check with accessibility team. | Remember, as we discovered with Drupal 7, there may not be established best practices to implement. Even small changes can mess up years of accessibility efforts, we will provide examples to help developers simple make a value judgements. | There will be a BOF at DrupalCon London to discuss & document this better. |
| Problem Patterns | We know that there are some patterns that will likely present barriers to some users. | If your patch uses things like modal dialogs or interactive jQuery calls then there will likely be accessibility problems. | We will generate a list of known problem patterns |
| User Testing | In your sandbox with the patch applied test how it works without a mouse. | Doing keyboard only testing helps pick out some barriers or better yet unplug your monitor after you have set up a screen reader. This won't necessarily ensure that there aren't barriers, but it will cut out some of the common ones. | Links to pages with docs on doing this |
| Accessibility Goal | Remember that the accessibility goal for Drupal core is WCAG 2.0 AA. | If not WCAG 2.0 AA it should be an add on feature. We want to reduce barriers to ensure that sites are Percievable, Operable and Understand by everyone and that the site is Robust enough to allow people to choose from a variety of technologies to use. | We will show concrete examples of each point of POUR, where possible pulled from core, and link to the relevant issues in WCAG 2.0 documentation. |
Comments
Suggested gates
After a few e-mails earlier today here is my suggestion:
(Design) For new UIs, or significant changes to existing UIs, consult with accessibility team to identify potential problems. This can be done by tagging the issue "needs accessibility review", or by starting a discussion on gdo/accessibility
(Prototyping) For new UIs, or significant changes to existing UIs, where the accessibility team has indicated during the design phase that there may be problems, include users with disabilities and with a variety of assistive technology in testing of prototype.
(Implementation) Ensure that any new UIs, or existing UIs which are changed by a patch, comply with all success criteria of WCAG 2.0 level AA. * note: maybe we can put together a handbook page that lists all AA criteria, with visibility settings to hide success criteria for multi-media, and some others, which will make the list easier to understand.
(Implementation) Ensure that new authoring tool behavior, or existing authoring tool behavior which is changed by a patch, complies with all principles of ATAG 2.0 level AA. * note: I figured we would use the high level principles here so as not to get resistance about a second set of criteria to understand, basically if tool UI and output conforms to WCAG 2.0 this is a pass..
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Great initiative. I would
Great initiative. I would suggest to determine which Drupal aspects are vulnerable to accessibilty issues and give some tips on these particular cases:
- multimedia (video players, graphics, images, embedding, flash, etc)
- cck field formatters
- fancy UI (drag 'n drop, popup, lightbox, etc)
@ezufelt good to mention ATAG
I'm finding it hard to
I'm finding it hard to buy-in to #3 comply with all success criteria of WCAG 2.0 level AA. The simple reason is that the success criteria are not clear cut, which means we will end up debating interpretations - granted this will happen anyway, I am nevertheless worried we will end up with endless bikeshedding around am ambiguous set of criteria. In D7 we made, afaict, WCAG AA a goal, not a hard requirement. I think we understood the need for pragmatism, especially in regards to the WCAG which is, lets face it, somewhat flawed.
I'm not sure about that
One point to remember is that companies and organisations wishing to build websites will increasingly specify WCAG 2.0 compliance as something that must be delivered. If developers can rely on Drupal to deliver on at least AA compliance, to me, that really puts Drupal at the top of the list.
I'm not saying WCAG 2.0 is perfect; I'm sure it is flawed. But I would rather us debate whether or not any success criteria is or is not met than debate the principle of whether it should be met.
Everett is proposing that we
Everett is proposing that we meet ALL WCAG LEVEL AA SUCCESS CRITERIA. That is not a principle, that is a hard requirement. Those are tough words and a very, very hard to achieve - given that you have not been through the process of building a new version of Drupal (I worked for nearly 3 years on Drupal 7) its very easy to be idealistic about this and simply state "we should do this because its a good thing", however it leaves no room for pragmatism, practical consensus or, indeed, actual accessibility improvements. Even the WCAG fully admits this is not the case.
What I want is the best, most accessible version of Drupal we have ever built - I am less than convinced that imposing the success criteria as the be all and end all gate is the ideal way to go about this.
Totally agree
Well said Jeff. I completely agree. Endless bikeshedding needs to be avoided at all costs. We need to keep morale high, so "gates" need reasonable and practical (and not just for accessibility). As long as the accessibility team is involved and we all work together from the beginning (covered in #1 and #2), we'll be okay IMO.
What's so ambiguous about WCAG 2.0?
Jeff, having tried to apply accessibility criteria to websites since before WCAG 1.0, I have to ask what aspects of WCAG 2.0 you find ambiguous. Unlike WCAG 1.0, WCAG 2.0 is quite clear as to whether an interface passes or fails.
I agree that the support documentation is, so far, not all we should expect it to be. For example, it's hard for a developer to quickly find the answer to a specific question such as, "What do I need to do to make sure this form field is accessible?" It would be great if the W3C had an index that pointed people to the success criteria they need to consider as well as to examples of successful implementations that might answer their question. I, for one, am doing what I can to change that.
But, independent of the improvements the W3C's various working groups are able to make, we — the Drupal community — can improve things ourselves. We can do that by submitting examples of successful implementations in Drupal or on websites built with Drupal. Those examples can be added to the W3C's list, so anyone who is using Drupal, evaluating a patch for Drupal, or even contemplating developing a website in Drupal can see at least one answer that is clearly recognized by the W3C as conforming with WCAG 2.0 at Level AA.
And by doing so, we would actually be helping the W3C create better documentation. After all, an index is worthless if there is no content for its entries to point to. And the specific example of an accessible drag-and-drop widget in Drupal won't be on the W3C's site until someone submits it as a successful implementation of a keyboard-operable drag-and-drop UI. After that happens, there could be an index entry that would point developers who wonder how to make a drag-and-drop UI accessible straight to that example of a successful implementation, saving them from having to educate themselves on the fundamentals of accessibility just to get a quick yes-or-no answer.
Looking back over the development of Drupal 7, I can't think of any cases where the issue was that some of us felt that a UI did conform with WCAG 2.0 Level AA while others felt that it had not. I can think of a lot of cases of keystrokes being wasted over whether accessibility was important, and even a few cases of energy being wasted over whether an imprecisely defined concept of usability or a precisely stated requirement for accessibility was the more important consideration. Please correct me if I am wrong.
Hopefully, the various gates will end those disputes. But also the more widespread adoption of WAI-ARIA, AJAX, and similar solutions should make the perceived competition between accessibility and usability a much less frequent phenomenon.
I'm going to write a longer
I'm going to write a longer reply at the bottom and propose my own set of gates. I don't think there's a lot of value in picking apart the spec line by line Cliff, you know as well as I do that we could be here for months arguing various points of contention.
I think we worked very hard to put accessibility on everyone's radar in Drupal 7, and it succeeded. Moving from a position of championing accessibility to one of enforcing accessibility is the wrong move - rather than solving debates we will end up with stalemates and no one wanting to touch "too difficult" issues because the time and effort needed to solve them is too burdensome. We already saw that happen in D7, lets not make the same mistake in D8.
Look, all you guys know I am a fervent accessibility proponent and by and large I agree that the WCAG is a reasonable specification, however I do not believe that by simply making Level AA a mandatory requirement will automatically result in a better Drupal, partly because the spec itself and partly because the practicalities of actually implementing such a thing will be very difficult - both in terms of actually coding this stuff, but also actually getting anyone to do it.
What I think we should do is, as we did in D7, use the WCAG as a guide (it is after all a set of guidelines), and as most other organizations do we have a mechanism for coping with non-conformance. We will also need to decided on a case by case basic what conformance means, in terms of practical implementation.
Actually, I don't think we could argue for months...
Jeff, WCAG 2.0 was developed by a team of developers and other experts from around the world. And they did a pretty darned good job. I've never found it hard to determine whether a particular interface conforms with WCAG 2.0. The challenge is in trying to bend a particular interface that fails to conform to make it do so — especially when, as was the case with Overlay, the simple and quick method for ensuring conformance is politically impossible.
There was only one reason Overlay couldn't be made accessible by providing a way to turn it off. And that is that a self-appointed group of usability "experts" had decided that Overlay was the one and only way to fix the usability problems in the admin layer of Drupal 6 and were so bound and determined to force everyone to use Overlay that they would not hear of adding any effective means for choosing it rather than having it forced upon you.
The problem wasn't understanding WCAG 2.0.
The problem wasn't applying WCAG 2.0 to the interface.
The problem was a refusal to believe what people who know accessibility, a fairly specialized discipline, had to say.
The problem was a failure to imagine Overlay as an added feature to advertise — rather than as the only option.
Look back in the issue queues. See where having "Overlay Off" be default with the option to turn it on was first mentioned. That would have solved the problem with accessibility, but Overlay's true believers said, "No."
And, yes, that led to many delays and a lot of extra work. Because dealing with strong denial is never easy.
I am obviously going to
I am obviously going to respectfully disagree with Jeff and Jacine here. WCAG 2.0, though it may be "flawed" or hard to interpret is the international guideline used as the basis of many government regulations around web accessibility. This is the guideline at the basis of the CLF 2.0 regulation for .gc.ca domains in Canada (or will be very soon), for the Accessibility for Ontarians with Disabilities Act (Ontario), for the revised section 508 (US Federal government, coming soon), etc. WCAG 2.0 is the current W3C recommendation on making web content accessible to persons with disabilities, it is what we have been aiming at for the past 2 + years with Drupal, and it is what we have in the past decided upon as an accessibility standard for our community.
So, we should go with WCAG 2.0, and we should aim for conformance with the AA success criteria. If there is a situation where it is not technically feasible to meet a success criteria, therefore not meeting the gate, then an exception can be made, as I am certain that one will be if it is not technically feasible to meet other gates.
It is important to remember that some success criteria will not apply to Drupal core. We will likely not see multimedia (audio / video) in Drupal core, we will likely not see flashing content, we will likely not see text embedded in images. And, we have actually already gone a long way to meeting WCAG 2.0 AA with what is currently in core.
If there are any particular success criteria that people would like to consider for a general exemption then lets discuss those. But let's have some use-cases, and persuasive argument, not just a statement of flaws and difficulty in interpretation. In situations where a success criteria is difficult to interpret I would be happy to contact a colleague / friend at W3C / WAI for further clarification.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
I have no problem aiming for
I have no problem aiming for it. As you said, we have done that for the last 2+ years and I think that should continue. I think it has worked out pretty well. The problem here is that setting a hard requirement for a spec you admit is "'flawed' or hard to interpret" is setting us all up to fail here, which is not practical and potentially harmful to the process. That's all.
Where is WCAG 2.0 difficult to interpret?
Jacine, can you give us an example of a case in which it was difficult to determine whether a feature conformed with WCAG 2.0 at any level, whether A, AA, or AAA?
The only point that has ever been brought to my attention is the one about language being programmatically determinable. All that means is that the document's principal language must be specified in the header content and any phrases in other languages must be tagged to indicate their language. But that "capable of being programmatically determined" part is hard for a lot of people (me included) to understand.
Other than that, where is an example of its being difficult to know whether a UI has passed or failed?
It's not about whether or not
It's not about whether or not it's easy to determine whether a feature conforms with any level of WCAG. This isn't what I'm trying to get across here. See Jeff's reply. I'd just echo every word, especially the last part.
Unrelated to accessibility efforts, there are places where Drupal's markup does not properly validate. There are places where designs have suffered, and where markup greatly suffers because there's no practical way around it. The point is, sometimes it's really hard, if not impossible to be standards compliant in general. It's not for a lack of trying, and it's not something we like, but we don't halt development because of it. We do the best we can with the resources we have.
There are a slew of open accessibility issues that relate to themes and drupal.org itself. By these requirements we'd have no Overlay module, a feature that has been widely successful for Drupal 7's user base even if it's not perfect and some of us don't like it despite all the blood, sweat and tears that went into trying to make it accessible.
I want to see Drupal's accessibility improve with every new version, but I do not want to see these gates hinder the Drupal project. So, what I am saying here is that I'd prefer that compliance with WCAG 2.0 level AA be the target goal, but not a hard requirement. I think this worked well in Drupal 7. At the end of the day, any issues that arise will be discussed and the community will come to a decision on that particular issue, but this is just my 2 cents on the issue.
The point is, sometimes it's
Yes yes yes, this is my point exactly. Its a very big ask to demand anything in a open source project, the more pressure and demands we make the less likely people will want to be involved - I watched this happen in Drupal 7, especially near the end when people were tired and simply walked away from of the some really difficult issues.
No, no, no
Once again, it was not hard to have an accessible interface in Drupal 7.
It was just impossible, with the options then available, to make Overlay be the one and only fully accessible interface in Drupal 7.
We, the folks who know accessibility and offered our input, were flexible. But the people who believed that they had conceived the perfect interface for Drupal stood firm: Drupal 7 would not ship without Overlay being the default, and it would not ship with a readily apparent means of turning Overlay off.
And, you see, that's where the basic misunderstanding of accessibility comes in.
Accessibility isn't about making the one and only control work for everyone. When that will work, great. But when it won't, everyone must have a control they can operate.
Holding fast to a single solution will always prevent you from creating a fully accessible product.
This sounds better Everett,
This sounds better Everett, as you know I am very much in favor of this approach also.
Using the WCAG as a guideline and having a mechanism for coping with non-conformance is the way to go.
If we can roll that into the gates with the right wording then I am on board.
We cannot predict what these will be, we will need a general mechanism for dealing with non-conformance. For example we can argue to the cows come home that we should do this or that, but if there is no one available to fix the issue and bring it into conformance then we need an exemption, regardless of the actual success criteria. That is the real argument here Everett, that demanding conformance is impractical in a volunteer open source project.
I don't actually believe the
I don't actually believe the spec to be as flawed or hard to interpret as others, any spec including html5 has some of these characteristics I'm sure.
As far as flaws go, we can discuss general exceptions, should anyone wish to raise any. Regarding interpretation, we can make decisions as a community, and then document these and apply them consistently, as we do with Coding Standards etc.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
@jacine FWIW, I don't
@jacine
FWIW, I don't consider the inclusion of Overlay in D7 to be something that causes D7 to fail to conform to WCAG 2.0. We likely need to tidy it up a bit, so that it is more accessible for users of most modern technology, but that is a separate open issue.
Since we are providing a method to disable the UI, and since no real functionality is lost, it doesn't seem to be a failure to me. Perhaps someone else can point out a success criteria which would fail, but I wouldn't consider it to be a fail. Now, if we used Overlay to progressively enhance the UI, then this would be even better. For example, there is no reason that the prior non-admin page cannot be made available as a link somewhere when Overlay is disabled and the user is on an admin page, there may be an open issue for this too.
All that being said, IMO, Overlay currently makes a site more difficult to use for screen-reader users, that doesn't mean that it is inaccessible, and doesn't make D7 non-conforming. Some UI design patterns will inevitably be more difficult to use for one set of users, and easier for another.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
OK, moving on to point two -
OK, moving on to point two - Prototyping:
We need some clarification on "include users with disabilities and with a variety of assistive technology in testing of prototyp" (sic). This could mean anything from an RTBC from a single user to fully fledged lab based accessibility testing.
Process to handle exceptions
To avoid bikesheds all we need is a process to handle exceptions. Certainly there will be exceptions or situations where we (the community) don't all agree.
Here is the process for exceptions that is described in our Drupal 8 Accessibility Ideas Wiki (http://groups.drupal.org/node/133034):
Do you like this? Or dislike it and have a different suggestion?
www.pixotech.com
My biggest objection to this
My biggest objection to this is the process - it centralize its decision making into a very small group of people and by the very words used, leaves little room for discussion and broader involvement.
IMO this is not how the gates are meant to work. Please read the OP:
That does not say anything about centralizing decision making in a committee of self appointed experts. Success Criteria could very well place a enormous burden on developers, not just on single issues, but on Drupal core development as a whole. We need to be very careful how we manage our most valuable asset - the developer. We piss them off with hoops of fire to jump through and we will loose them, not only that, you want to completely disenfranchise them by locking them out of the decision making. That is not going to work.
Look, I can only go buy what you have written here, and to me this stinks.
As raised earlier we should make Level AA a guideline and a high priority goal, that seems like the most sensible route and will get the broadest buy-in.
Checkboxes don't work for accessibility
If they did, the review could be fully automated. The best estimates are that maybe 27 percent of the success criteria of WCAG can be checked by automated means.
So we will need some flexibility in applying the concept of a gate to accessibility. Steps to check off might work for the rest of Drupal, but we need a ramp. ;-)
Replace "developer" with "accessibility professional" and I'll agree.
And by stacking the decision process in our one gate with the votes of folks who know nothing about accessibility, you will essentially be blocking us out of the process.
Don't underestimate the selling points we've brought to Drupal. At least one U.S. governmental agency that chose Drupal as its content management system because of its accessibility is open to considering WordPress — if WordPress can ever become comparably (to Drupal) accessible. That's not the only source of competition. WordPress is highly popular in the GovLoop circuit. And the WordPress community is asking, through social media and elsewhere, for input about making the product accessible. If WordPress does pass or even approach Drupal in accessibility, you might well see lots of government sites making the switch.
By contrast, no one asked for our input to Drupal. We realized the shortcoming, worked diligently to educate others, and helped in every way we possibly could. We have also announced in various forums, at some risk of our own reputations, that if you want an accessible CMS, Drupal is the one to go with.
@Jeff There is only a small
@Jeff
There is only a small group of persons with accessibility expertise in our community. This might hurt some peoples feelings, but it is a fact. I know little about performance, I should not contribute an opinion on that, and if I do it should not be given much weight.
I have, however, clearly misunderstood the purpose of gates. I will say that I see little utility in having an accessibility gate, if it means that we are not using success criteria.
Perhaps something like:
Evaluate the UI against WCAG 2.0 AA. If the UI is non-conforming open related issues for follow up bugs.
This means that we would still be committing inaccessible UIs (a bad idea IMO), but that at least the conformance problems would be documented prior to committing the UI. The accessibility bugs that are generated in such a process can then be prioritized, and may themselves be release blockers, depending on severity.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Open vs Closed
Its not about who has the expertise or who doesnt, its about the closed process - the process should be open.
The process is open
Join the team. Show you can do it. Then help make the decisions.
And it kind of is about who has the expertise and who doesn't. More expertise with usability might have kept us from getting boxed into Overlay as the sole choice of interface for Drupal 7. ;-)
I'm not saying that Overlay isn't a largely successful design. I'm just pointing out that it doesn't work for everybody — including a number of people who can see perfectly well. So making it all but impossible for people to turn Overlay off was a problem.
It was that choice, not issues of accessibility, that delayed Drupal 7.
I think this is a really
I think this is a really interesting discussion, and one that would inevitably happen with standards such as the WCAG 2.0 AA. Jeff raises an important part, all of this has to be clear and digestible for developers working on small issues to the big ones.
As I see the discussion, the current arguments against WCAG are that its; hard to enforce, because exceptions will occur and exceptions as proposed will be handled by a committee, rather than the larger community. I think especially the latter is a big concern, our current process is definitely a though one as the overlay discussion demonstrated - some people interpreted it as; it does not meet our WCAG 2.0 AA guideline directly therefor it should not go in, while others interpreted it as we do not have to comply here because we don't lose functionality or ease of use.
One bigger point against, that I see is to quote Jeff "that demanding conformance is impractical in a volunteer open source project.". Which to me is more focused on the fact that we simply do not have the resources required to make Drupal fully WCAG complaint, even the evaluation process to do this would be very extensive.
On the flip side, WCAG is one of the few standards we can actually have as guideline. It's universally understood as a standard for accessibility, adapting this standard might attract a whole bunch of new contributors who are interested in accessibility and its at the very least "something" that developers can measure against. I think the biggest take away for any of these standards, especially as outline above that neither accessibility or usability requirements can be true "checkbox" standards - what they can be is guiding principles, with their exceptions and discussions about those exceptions. I think what's vital for something like a WCAG requirement to succeed, is a clear understanding how we handle discussions about exceptions. And in the end, it will always be "the best we can" - we can not make it more usable and/or accessible than whats possible with the resources at hand - a gate will not change that.
And WCAG needs to be the only standard for accessibility
We don't need to concoct our own standards of accessibility. We need to test our product against the standards that the rest of the world will use. And that is WCAG.
WCAG 2.0 Level A basically says, "We didn't completely blow accessibility off."
WCAG 2.0 Level AA says, "We are seriously committed to making this product accessible."
And the W3C does say that nobody should make a policy of making everything conform with WCAG 2.0 Level AAA across the board, but that is because conforming with some of the success criteria at that level does preclude conforming with other success criteria at that same level. I'm not aware of any situation in which that is the case for WCAG 2.0 Level AA.
If folks remain open-minded, there isn't an accessibility problem we can't overcome at that level. I've seen it time and again in Knowbility.org's Accessible Internet Rally competitions. And the key has always been to accept other ways of doing things when the first idea that comes to mind turns out to be less than perfect.
Some notes about the general philosophy of gates
This is a good discussion, that's raising some really tough questions. I can chime in with some general thinking/guidelines around the gate process, which might help clarify things.
All of these gates: documentation, usability, accessibility, testing, and performance, were enforced in D7 core by a small handful of experts in each area. This process is not scalable. Why?
We don't want to go through this again.
So the vision behind gates is not to give a small team of experts a document to point at and go "See? You need to talk to us first. Dries said so." It's to raise the collective IQ of the Drupal core contributors so that instead of a small pool of experts having to play "police" (often, after the fact) the entire community can take on this burden. This allows the team of experts transitions into a role of mentorship, rather than clean-up, and frees them up to be brought in on tactical support on really tough issues that really do need expert opinion.
So the point of gates is to tease out the information in the experts' heads in what they look for when seeing if a patch is core-worthy or not. Then take the most egregiously offending things that they experienced in D7, and put them down into simple language that less-expert contributors (such as core committers :D) can understand, along with ample resources for more information.
So relating back to accessibility, I think stating WCAG 2.0 AA as a goal we strive for is a good thing. But the actual gate itself needs to be broken down more basic, IMO, if we're going to transition to the point where 1000 developers can perform basic accessibility triage, and our 3 experts can work on really tough problems.
Does that make sense?
This is not about the Overlay
This about the process and the concerns some of us have about you these proposed requirements that every single issue that we work on will be subjected to - based on our experiences with developing Drupal 7.
Every single comment that has been posted here only makes me believe this should be a recommendation more, and this conversation is fairly reminiscent to the general interaction between the accessibility team and the rest of the community that we had in Drupal 7.
You are completely dismissing a valid concern and telling us that we don't understand accessibility and that we should join the team to become part of the decision making process.
This is completely unreasonable, totally backwards, and insulting to those of us that actually sit here as members of this group and that actually work on the issues. There were lots of really painful issues in Drupal 7 where people just walked away from the process. Issues were hijacked left and right and there were sometimes hundreds of comments for fairly simple issues as a result. I cannot even count the number of times where crappy "fixes" were attempted at the last minute, while at the same time updates would come through on random issues from members of the accessibility team asking for patches.
This is an open source, volunteer project. IMO, there is a serious problem with how some members of the accessibility team interact with the Drupal community. This may not be the intent, but from where I sit, I often get the impression that some members of the accessibility team believe that their cause/agenda is of higher priority and of greater importance than most everything else. There's a small group of you that pounce on the community the second you don't get your way. This shouldn't happen. There's no reason for it. At all. But it seems to be a recurring theme... The vast majority of issues for accessibility improvements for Drupal 7 were accepted and many of them were worked on by people outside of your team. There is no one sitting here trying to say that we shouldn't shoot for WCAG 2.0 Level AA, as a goal. No one has said that. No one is even objecting to the rest of the items that have been proposed. You say no one asked for your input, yet this post was created by @webchick specifically asking for your input.
Everett offered up 5 points. We are concerned about 1 of them. What we asked was that WCAG 2.0 AA be a goal as opposed to a hard requirement. Again, no one is saying it's not a good goal to have. The responses here are really disappointing and lead me to believe that the reason you guys are clinging to having this sort of requirement in writing is so that you can use it as a weapon if something is going on that you don't agree with.
Problems arose in Drupal 7 when code was committed without ANY gates. Shitty markup and CSS, no involvement from the front end community or accessibility team, etc. We all suffered because of this, and are committed to changing that this time around. If that's not good enough for you, you can choose to ignore our concern here if you want. You can fight tooth and nail for getting every single thing you want, but I guarantee you that you are going to have problems with developers in this community, myself included, when you are asking us for patches.
Revised gate suggestions
We are having some heated discussion, and I feel that we are all moving off focus of trying to find a set of gates on which we can build consensus. However, I believe that some valid concerns have been raised.
After having taken the above discussion into consideration, I am providing my revised suggestions. I believe that I have been able to take most of the concerns addressed above into consideration.
(Design) For new UIs, or significant changes to existing UIs, consult with one or more persons who have experience with designing accessible UIs to identify potential problems. This can be done by tagging the issue "needs accessibility review", or by starting a discussion on gdo/accessibility
(Prototyping) For new UIs, or significant changes to existing UIs, where it has been indicated during the design phase that there may be problems for users with particular disabilities, or users of particular types of assistive technology, ensure that the accessibility of the UI is tested with these disabilities and assistive technologies in mind.
(Implementation) Ensure that any new UIs, or existing UIs which are changed by a patch, conform to all success criteria of WCAG 2.0 level AA. If the UI is non-conforming at the time the patch is committed, open related follow-up issues for each conformance problem, ensuring that these issues are tagged with "accessibility", and are given an appropriate issue priority.
(Implementation) Ensure that new authoring tool behavior, or existing authoring tool behavior which is changed by a patch, conforms to all principles of ATAG 2.0. If the UI is non-conforming at the time the patch is committed, open related follow-up issues for each conformance problem, ensuring that these issues are tagged with "accessibility", and are given an appropriate issue priority.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
I follow this discussion with
I follow this discussion with great interest. Drupal is now used by two third of all governments worldwide and as such is becoming fastly a standard for e-government, so there is a need for WCAG. I was not involved in Drupal 7, but you all did a great job building this very advanced framework.
I can imagine that accessbility checks makes developing more difficult. I it shouldnt stop the process of creative development. The discussion started with the question for simple checks. So a check like 'don't forget your laptop when you go to Drupalcon'. As such this checklist will help you when submitting code.
Some of the proposed points seems no simple checks but sounds more like procedures of how gates should work.
In my opinion a checklist for accessibility would be something like this: http://webaim.org/standards/wcag/checklist Off course that is a very long list, so we could pick or integrate the 5 most important checks for Drupal.
Accessibility Gate Definitions
OK, following on from webchicks post I have formulated a set of gates. The gates need to usable by developers and outline a clear process over the life cycle of an issue, with actionable items at each point in the process. If we are too broad developers will be left not really knowing what to do, if we are too specific we could tie up issues and create stalemates (essentially the same thing, we need a balance).
Everetts notes above form a good basis, however we need to break these down a little more and formulate them into a clear road-map, something that dev's can easily digest and make decisions on.
In cases where there is no relevant or applicable Success Criteria rely on the experience of the Accessibility Team to make a formal recommendation and provide relevant links to documentation.
http://www.w3.org/WAI/WCAG20/quickref
http://www.w3.org/TR/UNDERSTANDING-WCAG20
http://www.w3.org/TR/WCAG20-TECHS
PDF and archives:
http://www.w3.org/WAI/WCAG20/versions/guidelines
Team vs. whole developer group...
Back to what webchick said above about the goals for the "gates" ... These criteria seem to rely heavily on having accessibility experts around at all stages. What we need in the gates are some ways for non-expert developers to determine whether or not, on a given issue, they should ask for the accessibility team to get involved or not. Otherwise, every issue might be tagged "needs accessibility review", even if it wasn't really needed.
Are there some automated screening tools that you could point people to for that initial "does this raise any accessibility red flags" question? Could someone write up a page on drupal.org explaining what types of changes are more and less likely to raise accessibility issues? What's needed here is a way for the entire community developers (over time, at least) to have the tools to make these decisions, because as webchick says, it's not feasible for the gate to be "The accessibility team signs off on this issue". It needs to be "this issue has been reviewed by developer x against these criteria/tests and it should be OK for accessibility".
Drupal programmer - http://poplarware.com
Drupal author - http://shop.oreilly.com/product/0636920034612.do
Drupal contributor - https://www.drupal.org/u/jhodgdon
We have this wiki page:
We have this wiki page: http://groups.drupal.org/node/18595 for reference and there are lists of tools here http://drupal.org/node/394094, which is a horrible page and needs to be split up. We will certainly need to gather and rewrite some of our docs to make them more digestible and give devs a fighting chance of going it alone.
There are certainly some areas that are far more problematic than others - mainly the UI and certain patterns are troublesome (drag and drop, modal dialogs etc), colors/contrast/font sizes, form elements etc. These are things that could be written up into a concise guide - aka the red flag type things to look out for.
That being said, as Everett alludes to in his very first comment many issues need real accessibility testing - that is they need someone who is disabled to actually test this stuff out using their assistive technology, on top of that the actual testing required can be intimidating - you will need Jaws, Windows Eyes ($1800 between them), NVDA and Voice Over, then test those (at least) in all the current major browsers and across platform! There are some things that do not need such epic testing, but many things do. Automated testing is useful, but is not a complete replacement for human testing.
Can devs be taught triage with screenreader tools?
Since NVDA and Voice Over are free as in beer, I wonder if we could start with one of them. Do some sort of tutorial or screencast (ironic) to explain to developers how to use them and how to tell when there are problem areas of an interface.
This will of course never substitute for a blind person who uses these tools daily going through and doing their own assessment. But it would save those extremely limited resources on much bigger problems, like a major administrative UI change such as Overlay, or a full, detailed review of Drupal 8 towards the end of code freeze in all of those browsers.
Yep, with some thought I am
Yep, with some thought I am sure we can come up with some sort of documentation + tools (accessibility testing kit?), something like that would be a boon for anyone working on CSS/theme related stuff because its pretty easy to understand the issues and test for them (color, contrast, font sizes etc), for example simply getting front enders to use Contrast-A would be great and save me a lot of time when reviewing patches.
Screen reader testing - if we can define where screen reader testing is needed then I think we can provide a scope within which developers could potentially use NVDA for basic testing. I'm not sure what that scope might be right now, however I am very much in favor of encouraging developers to start using this type of tool when they building new stuff.
And of course the automated tools, these are very helpful and will probably be the most useful to developers.
Screenreaders are complex tools
Screenreaders are complex tools. Anyone who tries to learn one just for the purposes of testing may misinterpret their inability to operate the tool effectively as an accessibility problem - I've seen it happen. I'd like to encourage a different method with a lower barrier to entry: keyboard-only testing. Keyboard accessibility covers a lot of the same ground, and it also covers some mobility impairments. For example, you can get a handle on the issues inherent in drag-and-drop and overlay interfaces pretty well just by unplugging your mouse. As a bonus, once you learn to navigate web pages with the keyboard, you can move around a lot quicker on well-designed sites.
Keyboard testing doesn't cover form field labeling or link text as effectively. However, automated tools and developer browser extensions will detect problems in those areas.
Possibly keyboard-only + some Web Developer Toolbar test?
Not sure exactly how to decide what is best in terms of the Accessibility "Gate(s)", but I agree that there is (or should be) a certain degree of basic testing that could be done by developers without depending on them installing and beginning to learn how to use actual screen reader software.
In addition to the keyboard-only testing that cboyden suggest, the Web Developer Toolbar offers a number of methods to modify a site's output in order to help test various things. For instance, it can "linearize" the output, provide visual outlines of the structural (h1,h2,etc) units, and it can quickly disable/enable CSS and images. The Web Developer Toolbar has the added bonus of being a tool that offers a range of other essential developer tools that are not related to accessibility, but that almost any developer would find useful if they have not already incorporated the toolbar into their development process -- i.e. it is a tool that developers either already know about, or would love to know about.
Web Developer Toolbar:
http://chrispederick.com/work/web-developer/
Thinking out loud here, I could imagine (at least) 3 levels of "testing" that might be thought about for Drupal:
BASIC simulated testing using a couple basic strategies including: keyboard-only navigation/functions, plus a couple simple tests using the Web Developer Toolbar, and validating the XHTML (syntax and semantics). Any developer should be able to do this.
MORE IN DEPTH simulated testing by any Drupal developer/themer who has installed and is trying to learn about various assistive software technologies, including specifically one or two different screen readers. This level of testing might also include some of the automated tests available.
ACTUAL testing by accssibility experts and people who use screen readers
I'm not sure that the Gates discussion is the place to separate out all these and define them all completely (and the separation may not even be useful for that purpose), but I wonder if this rough list might begin to get at distinctions between different levels of accessibility testing that might be possible by people who have different levels of expertise in accessibility?
In terms of automated testing, I don't think it is that helpful unless a developer already has built up an understanding of some accessibility issues and of the WCAG and ATAG levels. Some Drupal developers will have these skills (or quickly acquire them), but it may be unrealistic to expect all drupal contributors to develop enough knowledge of the WCAG and ATAG to be able to interpret automated tests in a useful way.
I really like the idea of finding a way to provide enough guidance for average Drupal developers/themers to do some kind of basic testing of features/code that would help provide a triage system for accessibility issues with Drupal.
Phil.
Actually Firefox already supports stripping CSS
View > Page Style > No Style
One can also use this bookmarklet:
javascript:(function(){var%20i,x;for(i=0;x=document.styleSheets[i];++i)x.disabled=true;})();
Lots of websites become barely usable or simply annoying when this is done.
However, the other features of the extension look interesting, especially if one no longer has to quit and restart the browser to apply changes to the user style sheet.
Charles Belov
Webmaster
San Francisco Municipal Transportation Agency (SFMTA)
I agree, screen readers are
I agree, screen readers are complex tools, as is the usage of them.
The keyboard only approach is a sound one, great idea - with keyboard testing, color tools, automated tools thats a pretty good set of tools to get started with - and not that hard to get up to speed with.
@Jeff "When there is a change
@Jeff
"When there is a change in the UI (user interface) or underlying code that may cause an accessibility issue."
How will developers know if this is the case? All significant UI changes need to be reviewed by someone who is experienced with accessibility.
"2. The issue may be either "postponed" or "needs work" (after the patch is RTBC and committed). This will be useful where the issue is a blocker, or has dependencies (other patches that must proceed first), can be further improved at a later time, or in such cases as technology changes and a conforming fix can be implemented (such as improvements to user agents)."
I think I would almost always prefer that accessibility issues be opened as new issues. It really doesn't matter to me how we arrived at an accessibility problem being committed to Core, what matters is that there is a clear summary of the problem and a link to the issue where it was discovered.
I note that there is no strong sense of accessibility issues actually getting fixed in your recommendation, I can live with that. However, there is also no recommendation that issues be identified in the design / prototyping phase, this is a show stopper for me, as it saves so much time and trouble.
Once developers commit to a solution they are far less interested, for good reason, in making major changes required to improve the UI (be they for accessibility or any other reason). Identifying problems early on allows for alternatives to be considered before too many resources are committed to a potential dead end solution.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
"When there is a change in
1) Right, this probably needs rewording, however I fear you are still somewhat missing the point of the gates - that they are to enable average developer Jane or Joe to identify, or at least ask the question "could this be a problem", and if the answer to that is "could be", then tag it. I'm not sure using the word "significant" is clear enough, or what constitutes "significant". I can make a one line change in the CSS and destroy the usability of all pages for certain groups of users, yet the perceivable difference to a normal sighted person is negligible - even improved. This is why I stripped the ambiguity out of it and simply said "all UI changes". One of us can tell within a few seconds if its a problem or not - and we need that tag to know what to look at (because there is just no way we can keep up the thousands of issues in Drupal 8).
2) How about we make provision for opening a new issue, if it makes sense to do so - some times an issue will start off as an accessibility issue, some will evolve into one. Lets keep provision for both - from my perspective I like everything in one queue because we should be trying to prevent new issues or regressions during the development of new code and user interfaces.
3) Not really sure I follow here, from my experience issues can develop at any stage, whether in design, prototyping or even late in implementation - so the review process and issues identification is constant and takes place at every phase of the life cycle of the issue. I think what you are driving at is that when we are building entirely new UI that we should bring in accessibility team right from the start? If so, yes, I think we should word that into the gate, its important to have that early consultation.
@Jeff Can we do: "When a
@Jeff
"When a new UI (user interface) is added, or when there is a change in a UI or underlying code that may cause an accessibility issue"
I think that it is necessary to check new UIs, but this still may need clarification. E.g. Field UI is a new UI, adding a new vertical tab to node/add/foo is not a new UI, but still * may * need a review.
2 and 3 I am good with based on your most recent comment.
I can form consensus around this.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Accessibility Gate Definitions 2
Re: http://groups.drupal.org/node/158759#comment-537529 with they updated "Issue Identification" from http://groups.drupal.org/node/158759#comment-537584.
Re: http://groups.drupal.org/node/158759#comment-537674 modified wording to help emphasize self-help, if this needs improving please advise.
New links added for ATAG spec.
In cases where there is no relevant or applicable Success Criteria provide a description of the problem and test results (if any) with links to any relevant documentation. If the changes or problems are major (such as a major new UI or change in Drupal core that affects the UI) rely on the experience of the Accessibility Team to make a recommendation and provide relevant links to documentation.
WCAG 2.0
WCAG 2.0 Quickref
Understanding the WCAG 2.0
Techniques for WCAG 2.0
PDF's and archives
ATAG 2.0
ATAG 2.0
Implementing ATAG 2.0
Some initial feedback...
...coming from the perspective of a developer not savvy about accessibility issues (aka 99% of Drupal developers):
So do all UI changes of any kind get tagged "needs accessibility review"? Even text changes? Or just new/dramatically re-worked forms? What if I just add a new vertical tab to an existing list?
How do you define an "accessibility problem"? What are common accessibility problems to look out for? How would I know if a patch I made caused one?
What tests can be performed to know this? What is WCAG/ATAG? What are Success Criteria? How can I know if my patch is in conformance or not?
Who does this review process? How long do I need to wait for a review process? How do I add myself to the list of people who can do reviews?
These are some initial thoughts, but in general this gate is raising a number of huge, flaming red flags with me atm. It is totally impractical for us to tag every single issue that touches the UI as "needs accessibility review" and sit around and wait for one of 3 people or so to "clear it" in some fashion, or mark it back to needs work, and then repeat the waiting process after fixes are made. This gate also does nothing to educate developers (and committers) on what accessibility issues are and how to fix them, beyond pointing them at 8 several-hundred page links and saying "Read this."
This is a recipe for scaring people off of core development entirely, IMO.
Comparing with the documentation gate at http://drupal.org/node/1203498, the main differences I see are the following:
Looking at this set of gates though, I'm totally lost. I have no idea what steps I can go through to ensure my code is accessible. I can't tell what specific changes in my patch might raise red flags. I have no idea what tools I could use to do some basic triage myself before putting it up for review. What it reads like instead is "Anytime you touch the UI, you are probably going to screw something up accessibility-wise. So tag it for review and then wait for someone 'blessed' to test it, then fix whatever they tell you. Repeat."
We don't raise the accessibility IQ of the community like that, and we don't help our accessibility experts focus on much larger problems that only they can solve.
Here's a counter-proposal, which might be totally wrong, but would be more along the lines that I was thinking:
Stuff more like that. This educates me as a developer what the major accessibility problems that crop up in a typical core patch are likely to be, it gives me a guideline on when I know whether it applies to me personally, and it gives me tools to go out and see if I've conformed myself.
Does that distinction make sense?
Educate Developers & Reduce Effort for Experts
I haven't been as active as I'd like to around this thread. It's been a busy week and I've been watching the comments roll in and very excited about all of the participation. This is a broad community with a lot of passion behind it which is great!
Thanks for the counter proposal @webchick. One of the problems is that with your approach I don't know if we can easily limit it to no more than 5 (which is in your original request).
I do really appreciate the drafts provided by Everett & Jeff to get the ball rolling on this. This is such an important process and it will be important that it is done right. Especially since there are new gates added we are going to make sure that there is an effort to ensure that this is done right. I also liked the suggestion by @pkiff to impose different levels of testing.
I don't expect that all core contributors will have read WCAG guidelines. They are written for academic policy geeks, not for web developers. We have a goal of making core WCAG 2.0 AA compliant, but we have to be looking at broader patterns & not focusing on every line of text.
This got me thinking that we should really be looking at the usability folks work on developing their gate which seems like they've almost got consensus.
I'm going to put out a list of things which I think are achievable for various roles that will help our community produce more accessible code. There's the 99% of Drupal developers, the people tasked with reviewing accessibility in each initiative, the accessibility gate, the D8 maintainer and finally some external review. We can do a great deal to enhance Drupal's accessibility internally, but I really can't see how we can crowd source a WCAG audit internally. It's exhaustive enough that to do a complete job I believe it has to be done by a 3rd party.
Most core developers:
- Should install & use the Wave Toolbar for catching stupid things like form labels & alt tags. We should never be in a position where a patch adds easily detectable known accessibility problems.
- Should read an accessibility 1 pager (yet to be produced) that outlines the importance & complexity of accessibility issues for this community. Something that can reasonably be asked of 2000 developers. I've written a short piece on accessibility for managers which may be a reasonable starting point.
All initiative accessibility leads:
- Need to be aware of broader accessibility issues
- Should be able to point out common issues that produce barriers to participation (contrast, keyboard only, modal dialogs)
- New patterns should be referenced against POUR (Percievable, Operable, Understandable & Robust) guidelines from WCAG 2.0
- Ideally they would run it through a screen reader like Orca, NVDA or VoiceOver
- If theme related, it should be run it through for color contrast
- should maintain a sandbox where assistive technology users can evaluate the initiative
The accessibility gates:
- Need run new initiatives through JAWS & VoiceOver
- Need to look for common problems with meeting WCAG 2.0 compliance
The D8 accessibility maintainers:
- Need to review the culmination of initiatives, particularly as we get closer to launch
External review:
- Pre-launch a 3rd party needs to evaluate core to determine if it meets WCAG 2.0 AA. It would also be important to have a focus group that uses assistive technology to review
These are just some ideas. Nearly 400 people participated in accessibility issues in D7. It may well be twice that for D8. We need to do all we can to reduce bottlenecks in the process and also to lower the entry points so that it is easier for people to begin participating. We also really need to raise the bar & work through more barriers earlier in the system so that Drupal 8 is more accessible than Drupal 7 (it would be pretty easy for one initiative to set us back).
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
I like this proposal. Two
I like this proposal. Two suggestions that might sometimes an issue as well:
We maybe miss input assistance for forms and error handling, but that is covered as well by the usability gate.
...
No we can't just miss out form inputs and error handling, if we leave it up the usability team it might look pretty but be totally inaccessible - we've all been there done that (Overlay 2 anyone?).
That's pretty disappointing
That's pretty disappointing to read. 3 years of serious ux work dismissed as 'make pretty' and blaming overlay on us. Surely you could be more nuanced about this?
My apologies yoroy
My apologies yoroy, you are right, I could have been more nuanced than that, it came out wrong. What I really meant is the usability team tends not to worry too much about the implementation in terms of code, which is not your concern, but is very much accessibility teams concern.
TBH it was written in haste and with a twist of tongue-n-cheak, I hope you know that I am not that silly as to write off UX as prettifying things.
Ah no worries then, the
Ah no worries then, the tong-in-cheeck indicator was missing ;-)
Form inputs are in webchicks
Form inputs are in webchicks proposal handled in text for non text (provide labels) and keyboard access. So this is focussing on Guideline 3.3 (Input Assistance: Help users avoid and correct mistakes):
3.3.1 Error Identification - If utilized, form validation cues and errors (client-side or server-side) alert users to errors in an efficient, intuitive, and accessible manner. The error is clearly identified, quick access to the problematic element is provided, and user is allowed to easily fix the error and resubmit the form.
3.3.2 Labels or Instructions -Sufficient labels, cues, and instructions for required interactive elements are provided via instructions, examples, properly positioned form labels, and/or fieldsets/legends.
3.3.3 Error Suggestion - If an input error is detected (via client-side or server-side validation), provide suggestions for fixing the input in a timely and accessible manner.
3.3.4 Error Prevention (Legal, Financial, Data) - If the user can change or delete legal, financial, or test data, the changes/deletions are reversible, verified, or confirmed.
But this is all already in Drupal core in the form API, or am I wrong? if so, it is not an accessibility issue for coders, unless we rewrite form handling or coders don't use the form API, but using this API is coding standard.
Its pretty easy to go wrong
Its pretty easy to go wrong with FAPI or use it poorly - this is the price of having a very flexible Form API, so dev's need to take note when building new interfaces that include forms. Also you can do little extras that can really improve the accessibility of forms, like wrapping checkboxes in a fieldset.
FAPI Needs a Review
I don't know if there is an initiative to review FAPI, but having been involved in the process in D7, there are a number of outstanding issues that weren't resolved. Some of them are around accessibility.
This is an area which could use some improvement I feel. Could you start an issue for these, tag it and then let us know where it is so we can get some momentum around it? It would be great to have more sophisticated error handling/instruction capability.
I'm not sure how to best address these issues in FAPI, but this is a good time to start thinking about them.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
open issues form API D8
http://drupal.org/project/issues/search/drupal?text=&assigned=&submitted=&participant=&status[]=Open&version[]=8.x&version[]=7.x&component[]=forms+system&issue_tags_op=or&issue_tags=accessibility
Are there more Form API issues not tagged with accessibility?
If these issues are fixed, do we have a form API conform guideline 3.3 ?
Is FAPI also conform ATAG?
Do we need to update the UI standards documentation to promote building forms in an accessible way?
ATAG
FAPI hasn't been evaluated for ATAG. It's had some review for WCAG, but not comprehensive. Some elements like proper use of fieldsets are still working their way into core.
Absolutely there's need to update the documentation to promote better patterns.
Brandon or Everett are probably the best to talk about FAPI enhancements.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
ATAG 2.0 in Drupal 8?
When I read the ATAG 2.0 requirements, there are a lot issues to deal with, for example this issue A.4.1.2 Setting Changes Reversible:
So all settings in Drupal (ATAG is not only for editors, but for all roles, including the admin) need to be reversible or with confirmation. Hmm.
Before adding ATAG 2.0 (note: still in draft) as requirement to the gate, we should probably inventarise if we can and should meet all the success criteria in D8, or if it is better to scan for quick wins (for example editor issues only), or prepare D8 for ATAG in D9, or to work on ATAG for certain developments only, for example the WYSIWYG-editor in core.
I'm totally agreed. Instead
I'm totally agreed. Instead of reading the whole standard thing and find where exactly the information to solve the problem, give them shortcut and understandable insight and steps. Then, it is actionable instantly. And the more easy it is, the more productive programmer is. And when people get productive, they learn along the way. Then they will find the use of standards and documentations as helpful resources, not rules, because they already understand basics from what they did everytime.
Before anyone need to read standard, they just need a simple understanding about what is usability and what for?. If people start with overthinking, that's not a good usability for developer too. And if usability team required developer to need a lot reading to understand, it look like the team still can improved usability standard themself. Easy is the heart of it.
For example:
Form Descriptions / Module help : Skip it if not necessary. Write 5 words instead of 10, if it understandable. Explain just 80% use case if the module is complex, so it is not overwhelmed and too little informations. Don't use technical term if not necessary. Give link for more technical details.
And not passing usability reviews is not a disastered, it is just you are smarter than normal guys do use web, just press "back" and try again. Just have fun and try often.
My first recommendation resource is Steve Krug's Don't make me think ,this is free chapter and take a few minutes to read, which will save countless developer time later. It's like 1,000X investment return when you already read and get it, save time and resource forever. Worth buying, it's a steal (No, I'm not a sellperson. But it so cheap compare to developer countless manhour to fix code, waiting for review or lab testing). Maybe Drupal can explain why and become affiliate ;P
How about something like "Understand usability and use it in 5 minutes" guide?
I'm not smart to start it myself. But I can join and help, but may need people to rewrite my english.
accessibility, not usability
This gate is about accessibility, not usability. Perhaps an introduction might help you: http://www.w3.org/WAI/intro/accessibility.php
webchick - I understand many
webchick - I understand many of your points regarding "how would I know what to do", and that is partly what some of the other discussion here is about - such as providing a list of tools developers can use to identify accessibility issues - most of which are point and click tools that then tell you what is wrong, including referencing the relevant Success Criteria.
My vision was that there would be a "checklist" behind the Issue Identification documentation link, along with a list of tools to enable basic testing by anyone.
For example we have a checklist here: http://drupal.org/node/465106
I made the assumption that anyone can do a review - I saw adding a tag as an alert to everyone, not only the a11y team.
Part of what needs to happen is for others to give us time
@webchick, many of your suggestions are reasonable, but I think Jeff's approach is the best. One way developers could learn that they have raised an accessibility issue is to see a links to an example of a successful implementation of a feature.
The W3C's plans for the information that it has put online about accessibility is that it should include the basic principles, the guidelines, and examples of successful implementations of each guideline. Right now, the principles and guidelines are there, but there are very few examples of successful implementations.
Developers like Jacine have done enough accessibility work in Drupal that we should be able to populate the W3C's site with examples of successful implementations of these guidelines in Drupal. And it just so happens that the guidelines where those examples would fit best — the Authoring Tool Accessibility Guidelines [version] 2.0 — are at a stage of development where the W3C is open to — in fact, begging for — examples of successful implementations of the guidelines.
A very short primer about WCAG and ATAG:
Because Drupal is an authoring tool, we need to pay attention to ATAG. So it really is quite fortuitous that we're having this discussion at a time when the folks working on ATAG are looking for examples of successful implementations of those guidelines.
They want to know what tools are conforming and how they conform. They want to feature those examples so anyone who has the questions @webchick is raising can skim the examples, see things that are similar to what they are working on, and infer from the examples what they might do to make their own project conform with ATAG 2.0.
And we could supplement those examples with an index on drupal.org, where a developer who is facing a problem could find the respective entry in that index and follow a link to the corresponding example on the W3C's site. For example, if you are working on a module that has or affects forms, go to the "Forms" entry in our index and look for links to WCAG. Just from the items listed under "Forms" in the index, you could get an idea of what you need to be aware of to ensure your module keeps Drupal's forms accessible.
The neat thing about the examples is that you should be able to find a whole spectrum of solutions to any one problem. One of them should work — or inspire the developer to come up with a better answer themselves.
Bottom line, Jeff's organizational scheme will work. We need to work on the supporting documentation.
And building that out will take time. As someone pointed out, we are all volunteers, so our time is available only randomly. I have other projects for the next month, so I can't do much in the meantime. But, as before, I will help when I can.
I am reasonably confident the
I am reasonably confident the organizational structure of what I have put together can work - however I am not sure I have the wording right, we need to empower developers more so and make this inherently evident in the gate.
You are right about the documentation, even the 11 Point checklist I linked to would need a big clean up and would probably end up being a 7 point checklist and a new page entirely as part some entirely new "gate docs for accessibility".
What we don't want to see is developers thinking they need to read the WCAG or have to dig through it all the time, that would be a big ask - we definitly need to listen to what webchick is saying here, they are legitimate red flags, we have to think carefully about this before committing to this prototype as the gate. I'm kinda waiting for Mike to get really involved in this discussion, I really want to see what he comes up with.
Weekend Gate Reflections
I spent some time over the weekend thinking about this challenge. I think part of the issue is that what is in the current definition is different than what I had assumed from the Chicago keynote. That is totally fine and understandable, but a short checklist isn't what I remember being discussed at the time.
Drupal 7 needs a comprehensive 3rd party audit. Someone has to evaluate what we have now to work from as a baseline. Government & businesses who need to make their sites WCAG 2.0 AA compliant need to be actively encouraged to donate either $$ or staff time to do a proper audit. We need a baseline and help pointing out elements that we've missed.
Gates as Checklists
As with the documentation gate if there are errors the core team will have a role in reviewing the work, but will be confident that the basics have been taken care of already. Spell/grammar checking the documentation is a unwritten part of the the documentation gate and as with the other gates simply being reviewed by developer x against these criteria/tests will not mean that it's won't need further work.
Accessibility is complicated, there are lots of different users we are trying to accommodate, what should be OK for accessibility, isn't necessarily the case. For the accessibility gate, as for others, we're looking for a process to deal with 80% of the issues. There are no simple checklists that can verify that we aren't inserting major barriers.
It was hard to have an accessible interface in Drupal 7. Finding solutions that meet the needs of a community as diverse as Drupal really isn't easy. Although there were a great many improvements in Drupal's accessibility (which is thanks to so many people), there are still lots of issues that haven't yet gotten into core.
We are either farther behind than other gates or more controversial, but looking at the others, this one seems to have the most debate. It is worth also looking at the usability, testing and performance gates. It could be that there is a larger community or that it touches more more aspects of Drupal. It could also be that it is inherently complicated. There's a great deal of skill in finding performance enhancements or writing documentation, but for the gate process it seems like a pretty simple evaluation. I do think that it will be harder for both accessibility & usability to have as much certainty as the other gates, but still think this will be a very valuable process.
What we are trying to do for our own site
My company's site isn't WCAG 2.0 AA compliant but is quite accessible. I haven't had the spare resources to put into a full audit and until I do so and set up mechanisms to maintain that I'm not going to claim that it is WCAG 2.0 AA compliant (even if it is mostly there already). I see that the best steps for producing an accessible site are:
1) start with a system like Drupal 7 that has undergone accessibility enhancements and where the accessibility issues are largely known already
2) use automated tools like the Wave Toolbar & A-Contrast to pick out obvious problems for your users
3) hire a 3rd party to audit your site so that you can have someone else look for barriers that an automated tool can't evaluate
4) bring in focus group of users who use assistive technology to look for further enhancements
5) make your site as open and welcoming as possible to submit feedback with accessibility problems that users may have experienced
These items will need to be re-evaluated from time to time. Even with this careful consideration, some patterns will inevitably be more difficult to use for one set of users, and easier for another, so careful consideration of your site's audience is important.
I bring this up because there are similarities between this process for one site and what would be required for Drupal core. The communities details are different, but in both cases it is a journey. I'd love to see an evaluation of the process used to get to our solution in D7 for CSS display:none; - it was enormously long and time consuming. It's also not something that could ever be fully addressed by a checklist.
New Gate Suggestions
I am going to edit the wiki rather than post my thoughts as far as the gates go in the comments. I've shown this as a draft to both Cliff & Jeff and am certain that there are still more changes that need to be made, but that this approach is doable.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
On review of the new gate
On review of the new gate definition I think we might be able to reduce this down to three essential points: 1. Testing, 2. Patterns, 3. Goals and Examples. This is pretty much the table in the wiki post simply reworked a bit. Thoughts?
Accessibility Handbook
We will document a list of known problem patterns.
Looks good to me
I think it's really about finding a way to express that so that it's understandable to the average developer.
@webchick - what do you think of this?
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
removed
Inadvertently posted from personal login. Removing.
Chas Belov
off the clock
Please add zooming to tests
Please add testing with zoomed text.
WCAG 2.0 level A requires that it be possible to zoom the text 200% without usability being lost. That is, if the site visitor or content author has, in Firefox or Safari checked View > Zoom > Zoom text only, the Web page or authoring UI does not become unusable.
There are multiple ways to achieve this zoom, and core and extension authors would do well to be aware of this and test the various zoom methods.
I realize that Drupal, being international, is going for WCAG 2.0 and not United States federal section 508. However, the San Francisco Municipal Transportation Agency, along with many other U.S. state and local agencies and all U.S. government agencies, is required to meet the accessibility requirements of that section. The draft for the upcoming section 508 version 2.0 includes specific requirements for zoom and reflow, not just zoom; of course, it is still a draft, but be advised.
From that draft:
Personally, as someone who uses larger text, reflow is important to me as I often overlook what is off the right side of the screen. And I certainly don't want a paragraph being wider than my browser window; the only thing worse than horizontal scrolling is having to do it with every single line of text.
But that level of detail probably doesn't belong in the gate. Still, the gate does, IMO, need to include text zooming as one of the tests.
As a prospective Drupal user, I have not had a chance to test whether the overlay UI is tolerant of larger fonts, e.g., if I have doubled the font size and the currently active overlay controls don't fit in my browser window, will I be able to scroll to access the unseen controls?
Not suggesting that these links neccessarily be included in the gate, but they outline some of the issues that I'm talking about:
Resize text:
Understanding SC 1.4.4 http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html
H87: Not interfering with the user agent's reflow of text as the viewing window is narrowed http://www.w3.org/TR/WCAG-TECHS/H87.html
G146: Using liquid layout http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS/G146
as listed at Techniques and Failures for Web Content Accessibility Guidelines 2.0 http://www.w3.org/WAI/PA/WCAG20/WD-WCAG20-TECHS-20081105/
And as for Section 508:
Draft Information and Communication Technology (ICT) Standards and Guidelines
Published in the Federal Register on March 22, 2010. http://www.access-board.gov/sec508/refresh/draft-rule.htm
Charles Belov
Webmaster
San Francisco Municipal Transportation Agency (SFMTA)
200% zoom and re-flow is
200% zoom and re-flow is something we've worked hard to include in all of Drupal core. Toolbar and the Shortcuts bar are probably the most fragile in this regard, but should still preserve readability up to 200% unless you have a very narrow screen, anything around or over 1024px wide should be OK.
Typically text zoom shouldn't be a problem in the Seven theme, however its worth noting in the documentation (the docs that will accompany the gate) since its such an easy test to perform and one that everyone should be in the habit of performing. Overlay should not present any special problems.
Correction
would correctly read:
Charles Belov
Webmaster
San Francisco Municipal Transportation Agency (SFMTA)
Accessibility Gate Definition 3
Here is a new draft of the suggested gate definition. This revision is based on the 7/18/2011 Skype meeting. The goal of this draft is to focus on the 90% of common problems which all core contributors can easily test for and correct. This will allow the accessibility team to focus its effort on the remaining 10% of situations, such as new UI patterns that require specialized knowledge.
More about Drupal core conformance and UI patterns
The accessibility goal for Drupal core is WCAG 2.0 and ATAG 2.0 Level AA. We want to reduce barriers to ensure that sites are Perceivable, Operable and Understandable, and Robust (POUR), and provide for the use of a variety of assistive technologies. It is important to think about accessibility when developing new user interfaces and to become familiar with successful and conforming implementations.
UI Patterns. Following existing user interface patterns already used in Drupal core will reduce the opportunity for accessibility or usability problems. New user interface patterns will likely require review by the accessibility and usability teams.
Problem Patterns. There are known patterns in core that are highly likely to cause accessibility problems, for example modal dialogs or interactive jQuery calls. If your patch includes one of these known patterns please check with accessibility team by tagging the issue with "needs accessibility review".
Testing is very important when introducing or redeveloping a UI pattern. If you are still unsure after running through the basic testing procedures, please check with accessibility team by tagging the issue with "needs accessibility review". The earlier a new or changed pattern is checked for accessibility the easier it can be corrected.
More about Automated Checking
Automated checkers do not guarantee accessibility and do not check all WCAG 2.0 criteria. Some criteria require human review and problems may be raised in the issue queue.
The WAVE Toolbar is a recommended checker. Other popular checkers include: the WAVE web app, FAE and the Firefox Accessibility Evaluation Toolbar.
Running the automated check before and after applying a proposed patch is important. Some parts of Drupal core cause errors or warnings in WAVE and other tools. New patches should not introduce additional errors.
More about Contrast
See http://drupal.org/node/464500 for background information and other color contrast tools.
More about #title and #title_display
In the Drupal Form API, the new #title_display property allows you to choose the proper location for a form label to be displayed. It prints the label in the chosen location or makes it invisible off-screen while still preserving its accessibility.
See the Form API documentation for #title_display.
It is not accessible to remove the label by emptying the #title property:
unset($element['#title'])... or by using CSSdisplay: none. Both of those techniques were used in Drupal 6 and earlier when there was no built-in support for locating form labels off-screen or as tool-tips.More about Javascript Accessibility
Keyboard accessibility is a major concern when creating Javascript-based widgets, UI interactions, and AJAX functionality. "Keyboard only" is when you only use the keyboard to interact with the user interface. Many disabled users cannot use a mouse or other pointing device. Try using each feature of a new interface without using a mouse or trackpad. Problems with keyboard only operations will quickly identify areas to focus on.
Another kind of Javascript accessibility problem is the visibility of content that is dynamically loaded or updated by AJAX calls. Using existing UI patterns is encouraged to avoid accessibility problems. New user interfaces of this type will likely require design and collaboration with the accessibility and usability teams. Contributors are encouraged to seek design assistance as early in the design cycle as possible by tagging any issue with "needs accessibility review".
Drupal core includes numerous examples of UI patterns that have been made accessible with Javascript and/or ARIA markup. These include: drag-n-drop tables, vertical tabs, the password strength checker, and auto-complete fields.
www.pixotech.com
Accessibility is never finished
Gentlemen and Ladies,
I'm very much a newbie in this group and with Drupal culture and conscious that its easy to jump right in to a group before one is aware of how it operates and its sensitivities. I hope my comments will be taken in the contributive spirit they are intended.
I think you guys are doing fabulous work and I applaud you.
Something that worries me slightly about the tone of the language being used is the danger of encouraging people to think that when they have done certain things then they have "done" accessibility. As I guess you will all know having been active in the field, people and organisations commonly use walls like WCAG to argue that they have done everything they need and therefore it is accessible to "you". WCAG is GREAT and an important first step (as is ATAG) but they no way guarantee accessibility. One size of any clothes never fits everyone and probably never fits any one person perfectly. So I wonder whether minor massaging of the text might go some way to dispel the notion that applying techniques and tools is all one needs to do (at the user face). For example, s/The goal for Drupal core is Level AA/A goal for Drupal core is Level AA/,
add to the advice on contrast that ensuring there is sufficient contrast will extend its accessibility to a larger number of people but will not be sufficient for everyone .... that kind of thing.
I love the approach you are taking identifying interface and design patterns that work well and ones that don't.
Andy - hope I didn't speak out of turn.
I like it!
+1 to Brandon's version.
I understand Jeff's concern about using WAVE (or another accessibility tool) to test HTML structure, but I still think it should be required. If a patch adds errors, it should be tagged with "needs accessibility review" and we can determine whether the error is due to the markup or the inaccuracy of the tool.
Regarding WCAG and ATAG, AA compliance is a goal, not a release blocker. IMHO this gate is more focused on preventing new errors than fixing current errors. That doesn't mean current errors won't get fixed, they're just not part of this gate process (other than preventing us from adding more errors than we're fixing.)
@dcmouyard on Twitter
Listing things that don't scare developers
We can't start with WCAG 2.0 guidelines & ATAG. I'm not sure that the accessibility team can yet speak authoritatively about ATAG yet, but even if we look just at the summary WTAG 2.0 page here:
http://www.w3.org/TR/WCAG20/
It is between 12-13k words depending on which scripts you use to count it. That's 44 minutes for folks to read just that page according to:
http://www.wolframalpha.com/input/?i=12069+words
I think if the 1000+ Drupal 8 contributors run into that test first they will just give up and assume that they will leave it for the accessibility folks to complain about.
The accessibility gate is supposed to be low enough that the vast majority of contributors will feel comfortable running through it (at least as I understand it). If the accessibility gate were to be implemented by accessibility experts I can totally see including the first point, but this has to be pretty simple for folks to bother with.
I'm not sure how to get around this though as I do really like the "When is this needed?" piece.
I think the "HTML structure meets WCAG 2.0" piece needs to be reworded.. I think WAVE (or similar) should be suggested to catch the stupid mistakes that have accessibility challenges. Thinks like labels with forms. In fact the "Form fields are labeled" could well just be rolled up into this item I think. I'm not sure how else to list this though. The structure of HTML isn't really being tested as much as common errors are being verified by automated tools.
This has been a long thread. I think we have to focus on things that we are actually willing to ask folks to do and for that matter explain.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Mike, it sounds like you are
Mike, it sounds like you are saying that the gate should be a relatively simple checklist which anyone can pick up and apply to a site and that the gate is not the ultimate goal, but a simple tool to help move towards that goal. Example:
Ultimate goal: Compliance with WCAG and ATAG 2.0.
Gate:
That's my understanding
I could be wrong here, but this is my understanding of the type of checklist that Dries wants. Things that were problems with D7 that can be simple enough that the average developer can check for them in the D8 development cycle.
Accessibility experts will be able to provide comments about more complicated issues like approaches to modal dialog, but we're not going to find anything that complex in a gate for D8.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
I would add to that
Charles Belov
Webmaster
San Francisco Municipal Transportation Agency (SFMTA)
Proper Place for ATAG
Based on these comments and @Hanno's below, it sounds like there is general consensus that ATAG is a goal for Drupal core, but that putting it at the top of the gate checklist is not appropriate.
I suggest we move ATAG compliance out of the gate table and down into the supporting text/handbook. Is that the proper place for ATAG?
I also like @Charles Belov's suggestions and I think we can work them in.
www.pixotech.com
We're going to have to
We're going to have to clarify more around gate point #2 - "HTML structure meets WCAG 2.0. When introducing new HTML structure or semantics, such as when changing templates or theme functions."
There is actually very little in WCAG about markup structure and I am not sure checking against an automated accessibility checker is going to yield meaningful results. For example WAVE toolbar can't deal with the complex structures HTML5 can produce and would think perhaps that a proper outlining tool + HTML5 lint would be better tools for the job. Nothing wrong with WAVE but afaict it cannot handle HTML5 sectioning. Also it cannot "see" hidden content using element-invisible, so a document might have correct structure and headings, but WAVE can't see them.
Thinking that the main people dealing with such things are going to be working on the HTML5 Initiative and are mostly front end developers then lint and outlining tools are far more familiar things.
HTML structure
I think that WAVE has been very useful for looking at things like doing quick reviews to ensure that label elements have been added to fields & alt tags are included.
It's pretty low level but it's really quite shocking how many times basic elements are forgotten and how a simple automated scan can cover the basic structural issues (like ensuring that a skip to main link actually has a valid target).
Never should these automated checkers be seen as a definitive resource on accessibility, but it's one simple tool that can get much of the low hanging fruit. It's also easy enough that any contributor can use it to review a patch. There may well be some new code which an automated tool just can't address when we need it. That's ok, but running it should have identified the stupid stuff that can so easily be overlooked.
All of these automated tools are improving. There may be some instances where one is better than another. They are probably going to change in the course of D8 development too.
The HTML5 lint tool you mentioned is it http://lint.brihten.com/html/help
It's not a matter of picking a tool, but being clear that automated tools should be leveraged where they can improve standards compliance & accessibility.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Possible to wrap up by Friday?
Since Dries wants to announce these gates at DrupalCon London, which is in 3 weeks, we basically need to wrap this up by the end of the week in order to give ample time for review and revision. Does this sound doable? How can I help?
Are we on the same page?
Since posting the Accessibility Gate Definition 3 draft above, we've gotten two helpful pieces of feedback from @AndyHeath and @JeffBurnz.
Does anyone else have thoughts? A lot of people were passionate about this before, and I'd like to know if the silence means we're reaching consensus. Remember that the goal of this draft was to focus on those elements which all core developers could learn to test themselves in order to catch the more routine issues. That would let the accessibility team focus our energies on the harder issues like new UI patterns.
Does anyone else have specific suggestions?
www.pixotech.com
ATAG 2.0
I am a bit hesitating to opt for ATAG 2.0 at this moment and at least it they are not of the same level: WCAG 2.0 is part of ATAG 2.0 (Guideline A.1.1). So we could opt for WCAG 2.0 or ATAG 2.0 (with WCAG included as part of it).
Some of ATAG 2.0 seems easy to implement, other guidelines might require restructuring Drupal core. I set up a wikipage where we can tag where Drupal is compliant to ATAG and what needs to be done: http://groups.drupal.org/node/164389
Some guidelines as A.4.1.2 Setting Changes Reversible might have a impact of all the admin pages of Drupal. I think we should first analyse the consequences. For now, it seems more realistic to me to go for WCAG 2.0 level AA for this gate, and have ATAG 2.0 level AA as optional for Drupal 8 and compliance for Drupal 9.
Re: ATAG 2.0
@Hanno, thanks for this feedback. We discussed ATAG and WCAG in detail at the April 5 Skype meeting. We determined that each standard is appropriate for evaluating a portion of Drupal. WCAG is appropriate for evaluating the public (anonymous) pages that Drupal displays and the theme templates that control these displays. Whereas ATAG is appropriate for evaluating the administrative tools. ATAG references WCAG and the two standards fit together, but we felt that there is a place for each.
Moreover, WCAG is important to list explicitly because it is more well-known by developers. There are testing/evaluation tools that reference conformance with WCAG guidelines. We want to be clear with developers that we do expect Drupal's output to comply with WCAG. It is a well-known international standard. If we removed references to WCAG, I think developers would be confused if we told them "We still need you to comply with WCAG but only because ATAG references WCAG". If we are going to ask for WCAG compliance, it is better to explicitly state that.
Does that make sense? I think there are strong feelings that we need both WCAG and ATAG at this time.
Regarding gaps in ATAG compliance, such as A.4.1.2, we all agree that Drupal core does not currently meet each and every standard of WCAG and ATAG. There are parts where core is not currently compliant. Just like our documentation standards or our coding standards, the plan is to "fix it as we go". As we build Drupal 8 and beyond, our goal is to close the gap and work towards compliance.
Regarding the specific "Setting Changes Reversible" guideline, I think it would be wonderful for Drupal core to establish an "Undo API". Then other areas of core and contrib could all follow the same pattern to provide undo capabilities in the admin interface.
www.pixotech.com
ATAG
Yes, I was on Skype as well and I really like to see ATAG implemented and this guideline really makes sense for a cms like Drupal.
WCAG is required by law for governments and educational institutions, ATAG not yet. So, if we set priorities for the gate, WCAG compliance could be a release blocker for Drupal 8, whereas ATAG could be a guideline?
Does that make sense, or do you have the feeling that there is enough developers' power to tackle all WCAG as well as all ATAG issues?
So,what will be the goal for Drupal 8 core?
I think we almost know how much work WCAG will be. But do we have an idea how much effort and time the ATAG exclusive issues will take? I have the feeling that most of them are doable, but that some of them might need a code rewrite of several modules. Should we do a quick scan on the impact and gaps of ATAG in Drupal first? And depending on the outcomes, start projects in core like an undo API, before we ask other developers to check in the gate process against all the ATAG guidelines?
Re: ATAG
Here is a proposed paragraph to address this:
"There are existing aspects of Drupal core that do not conform with all WCAG 2.0 and ATAG 2.0 Level AA guidelines. New patches should not introduce additional accessibility problems, and it is recommended that they improve the accessibility of the areas that they touch. Over time it is our goal that Drupal conforms to all Level AA guidelines."
I suggest adding that into the section called More about Drupal core conformance and UI patterns, which will become a handbook page that supports the gate. That paragraph could go near the one about "Problem Patterns".
Notice as well that the draft gate has this sentence: "Test before and after a patch to verify that the patch does not introduce new errors." The whole idea is that new patches should not make things worse.
In my personal opinion, I would guess that when Drupal 8 comes out it will be 95% WCAG compliant and 60% ATAG compliant. Until the day when we conduct a more formal evaluation, those numbers are just guesstimates.
www.pixotech.com
While ATAG may not technically be required by governments
While ATAG may not technically be required by governments, I'd expect that there is overlap between existing Section 508 § 1194.21 Software applications and operating systems and ATAG 2.0. I'd expect there to be even more overlap between ATAG 2.0 and the currently-draft Section 508 Refresh Chapter 4: Platforms, Applications, and Interactive Content although WCAG is specifically referred to and ATAG isn't.
A potential issue is that if there are provisions in Section 508 that are not in WCAG or ATAG, government agencies within the U.S. would still be obligated to meet any additional requirements of Section 508. I recognize from prior discussion that Drupal is international and not U.S., but just saying. Of course, until the draft becomes final, we have no way of reconciling what might be in the Section 508 Refresh that are not in WCAG 2.0 or ATAG 2.03
I'm not trying to inject Section 508 into the Drupal Accessibility Gate. If Drupal is as extensible as Drupal folks have been telling me, I imagine there could be a Section 508 Refresh module to deal with the few things that might turn up in such a reconciliation.
Charles Belov
Webmaster
San Francisco Municipal Transportation Agency (SFMTA)
Additional governmental guidelines
There are many governments that have additional guidelines for governmental websites. UK (http://coi.gov.uk/guidance.php?page=188), India (http://web.guidelines.gov.in/compliance.php) and the Netherlands (http://www.webrichtlijnen.nl/english) to mention a few. Practically it is impossible to put all these national guidelines in the gate for developers.
However, we can start in this group initiatives to get these guidelines in core, in distributions, in contributed modules or in helper modules. A Section 508 Refresh module makes sense, we could also build everything in the accessible helper module and include a configuration where you can choose additional relevant national legal requirements.
ATAG 2.0 compliance
I started a wikipage on ATAG 2.0 compliance of Drupal where we can put in the right column all compliance and non-compliance of Drupal for ATAG 2.0. I added some first remarks but it is a lot of effort to analyse this, and some of them are - at least for me - ambiguous to interpret. I would invite you and others to give feedback on each criterion.
If we add all the ATAG criteria to the gate we ask every developer to check and to fix unresolved meta-issues within his/her patch. If, as a solution for this, we permit patches that aren't compliant to ATAG, how do we distinguish between permitted non-compliance and non-permitted compliance? Would that require a special Drupal ATAG-exceptions list? Or if we accept patches that doesn't make Drupal accessibility worse, but neither improving accessibility while this patch is an accessibility issue, why should we check on ATAG at all?
Maybe I am wrong and is integrating ATAG as we go a piece of cake for Drupal, but I would suggest to first analyse this. I would prefer to first start the gate with the main issues of WCAG. If that works well, we can raise the level and make the gate more strict.
Hey, To give you an update
Hey,
To give you an update the usability gate is in its last draft at http://groups.drupal.org/node/158764 which includes the resource regarding UI patterns. The gates themselves seem fine, I am a bit concerned about the documentation (resources) which seems to be a bit sparse yet - I expect these to be turned into proper books?
Great
@Bojhan, what do you feel are the most important places where the documentation/resources are too sparse? Maybe we could focus on beefing that up first.
Regarding the supporting documentation, I am expecting that it would all get turned into handbook pages. So there would be 4 new handbook pages for the 4 sections of documentation which are currently all together at the bottom of the post. Only the table itself would be posted as the gate.
The UX gate is looking good. Upon first read, I can easily understand what is required. I especially like the "screenshot gate" to make it easy for people to give feedback. I see that the interface patterns book is coming together too. Great work!
www.pixotech.com
Moved to http://drupal.org/core-gates
Thanks so much for your hard work on this, everyone. This is a really solid first stab, so I went ahead and moved it to http://drupal.org/core-gates, where we can always refine it later if necessary.