They also have a companion document, Implementing ATAG 2.0 to define how authoring tools can help developers produce accessible web content that conforms to Web Content Accessibility Guidelines (WCAG) 2.0. It also defines how to make authoring tools accessible so that people with disabilities can use them.

It would be great if we could try to meet the new guidelines with 3.2 as much as we can.

Thanks for the link Jane, certainly one of the interesting elements to study, but I find it very interesting how many of the items say “If this is applied in a web application, please refer to the WCAG 2.0 guidelines” (not in so many words, but you know what I mean). Still, I know there’s more to it than just that so further study will have to ensue!!!

Since you asked, here are the results of my test with the new admin UI….

I use keyboard navigation all the time as this speeds up my work. I also work with users who have disabilities.

At the moment, the dashboard contains 9 (yes, NINE) links with Tabindex=1.
Tabbing through gives no indication of where you are until you hit the Quick Press when the cursor suddenly appears for the first time, but there’s no focus or highlighting to tell you where the heck it is.
It takes 3 tabs to get off the index.php, then another two to take you off edit.php. Once either is selected I haven’t a clue where the cursor goes to.
The only clue that the cursor is even on a link on the dashboard is the name of the files showing at the bottom of the browser.
To most people, these file names won’t say much. In order, this is the tab navigation:

index.php
edit.php
post-new.php (well, thats a new post but has a disappearing cursor if you select it)
edit-comments.php
profile.php
tools.php

Then nothing to indicate that the cursor has jumped over to Quick Press title. Nothing shows in the browser to indicate the cursor has moved.

Tab through Quick Press – can’t get to reset. No focus on “Submit for Review” and the colour hides the fact that the cursor is there.

Next, back to index.php
Then /?unfoldmenu=1
Followed by edit.php
Followed by /?unfoldmenu=1
Followed by profile
Followed by tools
Followed by /?unfoldmenu=1
Ending with site URL (outside of admin, with no warning that this is happening).

For each menu, navigating by keyboard to submenus doesn’t happen. unfoldmenu doesn’t inform the user about what this is for or does.

I’ve spent a couple of hours trying to work out how to use keyboard navigation in the new UI, and not having any success. I keep getting totally lost because I can’t see where the cursor is going.

@Elpie are you testing 3.2-RC? The “/?unfoldmenu=1” is gone from the menu there, but don’t think many tabindex attributes have changed. As far as I can tell we can drop tabindex almost everywhere making the tabbing “flow” better. Exception will be the title on the write/edit post screen and few others.

We can try adding some kind of CSS highlighting to selected links and buttons perhaps even have a setting for more accessible admin.

Removing the “/?unfoldmenu=1″ anchor has helped a bit but the backend is still a nightmare for keyboard navigation.

I don’t recommend the use of tabindex. It is one of those attributes that came into favour with people jumping on an accessibility band-wagon without giving any thought to structure and site architecture. WebAIM has this to say about it:
“The tabindex attribute was created to allow web developers to customize the tab order of web content. Most of the time, tabindex is not necessary. It should only be used in cases where the default tab order is not ideal and when the tab order cannot be changed by rearranging items in the content and/or by altering the style sheet to reflect the best visual arrangement. These cases are rare. In almost all circumstances, WebAIM recommends against using tabindex. ”

Relating to the new TwentyEleven theme – this cannot be navigated using the keyboard.
Also, for accessibility, it’s too soon to use many HTML5 elements. As of May, the findings in this report were still correct. http://www.accessibleculture.org/research/html5-aria-2011/
I recommend that the theme development team and UI working group reads that article.

Reply to self – the latest RC provides reasonable keyboard navigation of the frontend. There are a couple of places on single pages where focus gets lost and so does the user.

However, the plethora of H1 tags is bad, bad news. HTML (5 – to clarify) is still being developed. hgroup tags have been in and out of the spec and are very likely to be replaced. No browser recognises them anyway. There are debates amongst those of us working with HTML 5 over the use of heading tags but general consensus is that it is too early to mess with the document outline. Screen readers see those h1 tags as top-level so, for accessibility, it is far wiser to stick with the h1-h6 hierarchy until HTML 5 is further developed.

9th August, 2009, this was posted to the wp-accessibility list. I am reposting it here because it contains links to information I feel is important to keep, especially since the mailing list is being retired.

Ironically, since Joe wrote that evaluation, WordPress has gone backwards in some areas, despite making up a lot of ground in others.
It would be great to do a new evaluation against the current guidelines – this could help provide focus for this group.”

If anyone would like to take a stroll through 3.2 or the new default theme, Twenty Eleven, and identify any accessibility issues, now would be the time if we want to patch them before release. You can access 3.2 trunk by using the beta testers plugin: https://wordpress.org/extend/plugins/wordpress-beta-tester/

Any accessibility professionals interested in being part of the new accessibility working group, please leave your info in a comment on this post and I’ll get you added to the blog so you can introduce yourself.

I think you misunderstand this blog’s purpose. It refers to accessibility as in section 508, screenreaders, visual acuity issues, manual dexterity disabilities, etc. This is not about usability or design preferences, so the comments above are not really what we’re looking for here. That kind of stuff is dealt with over at make.wordpress.org/ui.

Hiya guys, I’ll give it a check over for you. I’ll check it against WCAG 2.0 and test for common accessibility issues (we don’t use Section 508 in Ireland). I’ll install locally and give you a report later. Any particular method of contact or is this forum ok?

On first impressions, I must say, VERY impressed at the improvement in overall accessiblity levels which have greatly added to my overall impression of WordPress. I’m also delighted to see HTML5 implementation in the Twenty Eleven theme, it looks great and will be a great example of a CMS moving with the times. There are one or two VERY small accessibility suggestions I would make.

First, there is no label on the Search field. You could argue that with the placeholder text, it’s not really necessary. For absolute conformation with the requirements, I’d recommend you add it. It can be hidden using an “accessibility-hidden” class or something to that effect which would have the following CSS in it:
margin: 0 0 0 -1px; padding:0; height:1px; width:1px; position:absolute; overflow:hidden;clip: rect (0 0 0 0);

Second, a minor issue on the theme colours. The edit button’s text against the background colour has a luminosity of 2.3:1. For AA WCAG, this should be a minimum of 4.5:1 and for AAA, it should be 7:1. Many other colours I checked that I thought wouldn’t pass do (and do by some margin, a learning experience for me!), so this is, I would suggest, a small change to make.

On this, there is a question doing the rounds of the accessibility community which is, if an element is styled like a button, why is it’s fallback not a but, i.e. why are we styling anchor links to look like buttons. It seems the most logical fallback on an element styled like a button is that it should be a button. Personally, I don’t have a problem with this, as using a button would require a javascript onClick event, which has it’s own inherent accessibility concerns (what if the user is one of the 2% of people not using JavaScript!).

Finally, I’m not sure how accessible you require the dashboard/backend of WordPress to be, but on the assumption that you do (to some degree), I would suggest that the code regarding the toolbar at the top of the page be moved, in the code, to the top of the page! Screen readers and the like will read the content from the source code in hierarchical order, regardless of style, so if this is the case, the very last thing the user will get to is the toolbar. There is the alternate arguement that they will have to tab through the toolbar before getting to the content, so maybe you could have another (hidden) skip link, that brings you to the toolbar at the footer, which is only shown when logged in.

I hope this has been some help. If I get a chance over the weekend, I’ll take another longer look at it. Otherwise, I think it is a vast improvement and well done on taking the time to do this.

There are serveral reasons for having the admin bar at the bottom, HTML-wise (listed in no specific order). One is speed. Putting the HTML (and the JS that powers it) at the top results in “blocking,” which makes pages slower to load. And if the HTML is up top, but the JS is at the bottom, then the bar doesn’t work for a variable amount of time. Second, it is better for search engines. Content should be nearer to the top, not buried under menu bars. Thirdly, it is better for accessibility, as you noted, in the respect that people don’t need to continuously get past all that HTML to get to the content.

Your hidden skip link idea is an interesting one! Thanks for the feedback.

No problems, glad to help. Fair points made there Mark, and I do agree with you completely about the load times, etc. I kind of thought about it while writing the suggestion, and it made more sense to me to have it at the bottom while I wrote my thoughts, which is why I suggested the skip link. I think it’s the only way to ensure accessing the toolbar (accessibly) from the top of the page.

Hi folks.
I’m simply a user of WordPress, and hope to test out the accessibility of the upcoming stuff you mentioned on the comments.
I’m a totally blind user, and primarily use three different Windows-based screenreader programs.
NVDA (Non Visual Desktop Access) JAWS for Windows from Freedom Scientific, also called (jfw) and also have in the last year began working with SystemAccess, from Serotek.com.
I was working with GWMicro.com’s Window-Eyes screenreader, but I’m growing tired of waiting around for them to rewrite the browse mode, stick aria support into there product, and such.
Until they do this, I will not be actively testing it with things.
Primary browsers I am using:
Internet Explorer Nine and Firefox Four.
I mention this information because is primarily what I have at my disposal for accesibility testing.
I’d like to know more information on how I can test (since I am blind) I won’t be able to ehlp you folks with visual based questions like color, and other little issues like that.
They’ll need to be about thigns like: if I can’t navigate by heading, if form feeleds are not properly labled, and so on.
One thing (though I could be wrong) was when I began using WordPress a few months ago, sometime last year, was that I found switching to a new theme to be toally inaccessible, no matter what screen-reader I used.
Has this ever been looked into?
I’m also curious if a time limit exists as far as gaining access to WordPres through the beta-tester plugin.
I ask because I don’t have WordPress presently installed.
A friend of mine is giving me access to a web hosting platform where I ‘ll be able to set this up.
As soon as I do, I’ll happily grab the beta-testing plugin you meitno, so will be saving this page to my favorites (assuming this post doesn’t go down soon) so I can remember exactly where to grab the plugin.
Searching the plugins is nice, but having the direct location is far better!
Take care everyone!
If using my primary email, I won’t accept spam. I get enoguh spam messages from epople I don’t know as it is. Just a point.
You’ll find my email in the comment submission form!
Well labled by the way, although I have one suggestion in future development right now on the comment form.
The last labled form you have is the “website:” edit box.
The comment box only says “edit” perhaps lableing it “comment:” would be better, so that all screenreaders would say “comment”?
Just a thought!
Having an unlabled edit box in any case is a bad idea (especially because it is probably to the majority fo new users who are blind and such using wp they might not know that you wish a comment to be present in that feeled. So they might think: “What”?
Anyhow that’s that!
One other public feedback for everyone here:
The replybutton however is labled so only the comment editbox is not.
Can anyone confirm if this is always the case ( regardless of theme)? If so, then this small but seirous adjustment needs to be made by the primary coders of WordPress (of wich I am not.)
I can only test. I cannot implement my own suggestion about a small suggestion like insuring that in future software releases beta or otherwise that the comment box is labled like this: “Comment:”
Without the quitees.
Our screen-reader will identify the box as an edit box if you folks code it properly, so just typing:
comment:
as the lable is good enoguh in future releases.
Please submit this feedback to Mat and th other primary developers, I’d appreciate that as a first-step of the future of WordPress accessibility!
Thanks a lot!

OK – first test I ran and it failed miserably! Please, please, don’t assume that every keyboard navigator is using a screen reader. The vast majority of them won’t be. The skip link isn’t available visually (and that’s a pretty basic fix these days) and there is absolutely no link highlighting. End result: you’re completely lost within about 3 keypresses (?sp).

And while you’re looking at highlighting for sighted keyboard navigators, what about some highlighting on form imputs that have focus? Again, very simple to implement but with a major impact on overall accessibility.

Contrasts – why black text on a white background again? That’s going to cause major problems for most dyslexic users and a significant number of visually-impaired users (ie those using screen magnifiers). A contrast of 21:1 really isn’t necessary for a default stylesheet. Dropping #000 down to #404040 (or even #505050) would still comply with WCAG 2 AAA requirements in terms of contrasts. Bizarrely, all links fail AA contrasts miserably (only 3.6:1), so I’m struggling to find the logic here.

The :visited link pseudo styling is also missing. I’d argue that could be an access issue for those with reading, language or learning difficulties. As could the removal of the underline on links. Mouse users don’t really need the underline onhover. They get feedback from their cursor. Some color blind users, however, may have trouble locating non-underlined links. Try greyscaling a page and you’ll see what I mean.

Not sure I agree with the plethora of H1 tags in terms of providing a logical and hierarchical header structure in order to convey a mental model of the page, either. Navigating the main posts page via a Headings List is going to be real fun!

Overall and after an initial scan, I’d describe my reaction as “disappointed”.

This is super helpful, thanks! Bear in mind that the theme team are designers by trade, not accessibility experts, so let’s not assume any decisions were made to impede accessibility — they were made to make a great-looking theme. If we all assume the best, not the worst, intentions and keep our tones in line with that, it makes critical feedback much easier to take gracefully.

Sorry – I hope that implication didn’t come across in that way. If it did, it’s probably born out of frustration as these are some of the issues I’ve been trying to battle against over many years. I think the situation regarding accessibility might well be summed up by a comment I published some years ago:

My own personal feeling is that, because visually impaired users have been early adopters of assistive technology and have, very successfully, highlighted the problems that they face, the balance within accessible web design has become somewhat skewed in their direction.

@esmi: Do you have a good link to information about why black on white text is problematic? If we can point the theme designers to information that can help rather than just telling them it’s bad, that would be helpful.

Body text appears to be #333, not #000; which text are you considering problematic? Could you take a picture of the issues as seen with a screen magnifier?

It’s been found that very stark contrast between text and background can be of hinderance to people who suffer from extreme dyslexia. This is often aided (especially for kids in school) by using glasses with tinted lenses to change the background colour in relation to the foreground i.e. printed text on paper. Reducing the foreground colour “softens” the text against the background and can aid making it slightly easier to read.

I would hasten to add that, like fingerprints, not all types of dyslexia are the same, in the way that not all colourblindness is the same. There will be no “one fix, fix all” solution for this but esmi’s points are quite valid.

I would point out to esmi though, that the CSS style sheet does have “:focus {outline: 0; }” which is accompanied with the comment “remenber to define focus styles!” This does push the responsibility back on the developers of the site to ensure that a focus style is provided for both keyboard and clicked indications.

As HTML5 has changed the use of headers to apply within specific articles or sections, there is now no longer a requirement for single H1’s on the page, but I agree with esmi, there should still be some rationale behind their application. I fear that removing the strictness of their hierarchy will lead to worsening accessibility support, but this is a conversation to be had with the HTML5 gods! WebAIM recently completed a survey with users who require screen readers and found (surprisingly) that just over 50% (of ~1250) expected to find two H1’s on the page. I think this is a conditioning thing; the developers have put two H1’s on pages for so long, that the users who require screen readers have come to expect to find them. That’s not to say it’s correct, but I think this is where the reason arises.

Yes, having a dyslexic high-schooler, I’ve been given the “have her read through yellow cellophane or tinted glasses” spiel. Was hoping for a link to an authoritative resource so the theme designers coud learn from the source (promote proactive rather than reactive responses, etc).

I don’t have any authoritive link on this at the moment, but I will see if I can find you something. I didn’t think the suggestions were as primitive as to cellophane, I thought opthalmists were aware of this and had proper solutions. As far as I am aware, it is very much hit and miss as to which colours work for the individual, though I believe variations of yellow or pink are best. I will do my research and get back to you.

First, I would like to congratulate WP for creating an opportunity allowing input from users to test the accessibility of upcoming releases. I will be encouraging my colleagues to take a look and provide input.

As for my own testing: I have downloaded the plugin and read the directions, but I am reluctant to activate and update my own WP blog with the new version for testing since it is not a test site and I need for it to work flawlessly. I don’t have a WP test site set up at this time so I’m wondering if others who have downloaded and tested the new beta version would be willing to post the URLs of their locations so I can have a look.

Another comment is that it looks like you have gotten some good feedback already. The issue of correctly labeling input boxes is critical and absolutely must be fixed – this has been a problem for a long time. I am less concerned about the Skip to Content issue – I understand there are others who are passionate about this. I’ve blogged about this recently – anyone really interested can seek that out. That said, I would encourage consideration of creating the WP core be written so that naturally the content would appear at the beginning of each node and the navigation at the end. The CSS of the theme can be used to relocate the navigation to where ever on the page you desire, but screen readers will “see” the content first thus removing the need for the “skip to” link.

The only other observation is to ask reviewers to please separate their discussions and recommendations regarding theme/styling issue from core function issues. Some of the concerns about contrast and layout are theme issues. While I understand that it is necessary that the initial install WP theme be accessible “out of the box,” let us remember that just about every WP user will install a new theme after they install the core. There are currently few theme builders out there who have build accessible versions – I hope more will appear in the near future. I suggest making the initial theme as “vanilla” as possible.

My last comment is that I believe good universal and accessible web design means allowing users of all types to be able to easily and effectively access content using whatever assistive technology they have. By this I mean attempts at creating a design that is focused on one group over another should be avoided. It also means attempting to employe assisting techniques (such as text enlarger widgets and color style changer widgets) are not necessary. Lest we not forget that a fully accessible website can be rendered inaccessible – or less accessible – by one user posting something. Accessibility requires vigilance and training/education just as much as it mean good initial design.

first of all template accessibility is quite good – there are some issues – I will tell about them. But getting the WordPress front end fully accessible is always a combination of templates, editor, plugins and widgets – a complex process. Let’s just keep that in mind.

I want only to bring issues for Twenty Eleven and it’s templates – of course one has to fix a11y issues in default widgets and plugins …

Most of the a11y issues are known and not took in consideration for a long time now – the better they will fixed soon.

1. color and contrast issues – even if you only take WCAG 2 AA in consideration there are some issues which are easy to fix:

the blue link color
grey text in input field
main navigation is not very readable
reply button and text
subheadline grey on white

2. keyboard focus: an ever lasting topic of WordPress keyboard focus is so easy to realize but never was – was also mentioned already in comments here.

no visible skip link on keyboard focus
aside normal links there is no keyboard focus – a keyboard user does not really know where he is on the website
there is one on forms – a transition making labels and required asterisk vanish. this is a really nice thing, but one has to remember what the field is for and if it is required.
drop down menu (main navigation) is not keyboard accessible – this is a heavy problem, because WordPress is not that good in orientation issues. And how should a keyboard user get to a sub level in main navigation apart from accidentally?
show room slider is keyboard accessible, but you get no focus to know that this is a slider

Also link hover and active state could be improved – it’s only css so far

3. heading structure
First I was really “shocked” that every headline was H1, but you are of course using html5 elements as aside which can contain a H1.

But JAWS doesn’t recognize this until now and has only to much H1 elements.
Also NVDA doesn’t interpret the html5 hierarchy until now.
There should be a choice if one keep the “old” hierarchy model to support screenreader users better than having a lot H1s elements. I know it’s not that easy to decide …

4. without color: content should work without color information

– showroom slider works only with background-color, so without there is only a white area.

5. Zooming: I tested page zoom and text zoom separately

– text zoom: the text in reply button get’s cropped, slider navigation in showroom’s featured post get’s over the post.
Also IE9 does not zoom the text in pixel – so it would be better to make text via css more flexibel.

– page zoom: slider navigation in showroom’s featured post get’s over the post.

6. Screenreader

search field and placeholder – JAWS and FF 4 is reading placeholder, JAWS and IE9 not, although I like this html5 form attributes, I fear the search field should have a title attribute to – while not having a label. And why is the search button integrated with display: none? Put him out of viewport would make a search for screenreader user more accessible …
required asterisk: also current screenreader support aria-required to mark a field as required, you should have a kind of fallback: the asterisk – but it should be put into the label to be read by a screenreader in form modus – also should there be a kind of info what the asterisk mean …
header image: should have a filled alt attribute – it is big and not in the background and the pictures are very nice – so every one should get them. Unfortunately there is up till now no possibility to add alternative text to the header images …

So – this was a quick review and for a more detailed analyses I have to have more time.

First off – Bravo to the folks at WordPress for making this effort. It’s just awesome to see this happening.

My first run through TwentyEleven, I see a few things that could be fixed, in terms of improving the accessibility.

1) The Search Form:
a) Put a label tag on the search form. If that just can’t be done, put a title attribute on the text input field. This input needs to be properly identified to assistive technology.
b) If hiding the Submit button must be done, position it off the viewport, do not set it to “display:none”. Use “position:absolute; margin-left: -9999px;” That way, it is still accessible to assistive technology. Jaws, for instance, has, in the past, recognized display:none & won’t know the element is there.

2) Links:
a) Please underline them by default. Begin from the position of improved accessibility. Let users remove the underline if they so choose.
b) Everywhere there is a style rule for “a:hover”, you should add “a:focus” to it. Keyboard navigation doesn’t :hover. If I’m tabbing through a site, the :focus selector is recognized. Which brings me to

3) Outline:
Setting the outline to 0 removes a handy device for non-mouse navigation of a page. While I like the acknowledgement of the need to set it in the stylesheet, Like the underlining of links, I would go ahead set it, allowing users to remove it if desired. What harm is done enabling it by default?

I’ve got some notes on making changes to the administrative side of WordPress – I’m presenting at Knowbility.org’s AccessU 2011 in Austin on accessibility in WordPress. It’s a brief talk, mostly focused on accessibility in theming. I’d be glad to share my notes & slides.

My main focus is accessibility testing and consulting in this area. Currently I’m leading the large team of testers in the huge project of testing accessibility of 200 public administration websites in Poland.

I’m also an avid WordPress fan and developer (3-4 websites per year on this platform) and I’d like to contribute to make WordPress more and more accessible tool for publishers and readers.

I can not only contribute with my expert skills but also test with many disabled friends using large bunch of assistive software and equipment.

Hi, thanks for doing the work to make the template accessible. A dyslexic coworker explained it to me as seeing the foreground and background switch when using black and white. That is, the white background moves forward. Muting the colors seems to help, although you must keep the contrast up. Good tools to use are available from Juicy Studio at http://juicystudio.com/.

I’m Philippe Vayssière from Strasbourg, France. I work for a web agency (alsacreations.fr) as a web accessibility expert and front-end developer and in my spare time, I volunteer as an admin for alsacreations.com, a french speaking community dedicated to web standards and accessibility. This year I also dedicate time to the Libre Software Meeting that’ll take place in July in my town.
Recent projects in the web agency I work for were all made with WordPress 3.x: yay for the Custom Post type and the ease of use for our clients

I downloaded WP latest, installed it and the beta tester plugin locally, then reviewed the twenty eleven theme from an accessibility point of view and modified it a bit. More or less, I came to the same conclusions than Tady Walsh, esmi and Sylvia Egger.
I’m going to install this modified theme online, that’ll be far easier to show and explain the modifications (:focus-related CSS rules, text zoom up to 200%, form elements, skip links moved and shown without breaking the design).

I couldn’t test things like featured post and image, .page-link, .recent-posts, .ephemera. I guess I’d have to create more (sub-)Pages, categories than I already did and maybe activate widgets, but maybe such a dummy content already exists (for automated tests by example)? Can such a thing be imported in a blank installation?

My experience in “taking a stroll…” is about the same as the last time I tried this (with Jane’s call to accessibility experts back before 3.1).

As with accessibility consulting nearly everywhere, one part of the organization asks for improvement while another wants to march on to the latest and greatest technology instead.

It ends up being a huge waste of time and interest when the accessibility consultant’s suggestion is answered with “I think that we are taking this ticket away from the subject and going back instead of forward. WordPress already stepped into HTML5 and this big improvement must not be degraded in any way, …” (see: https://core.trac.wordpress.org/ticket/17611#comment:58)

Jane, you can’t expect accessibility experts to stick around and help when they’re met with these kinds of attitudes.

Bit late to this page I know, but just wanted to highlight a couple of points:

Firstly the issue of keyboard accessibility. There are so many sites using the default WP theme now so it is imperative that any dropdown (or flyout) menus are keyboard accessible. The default theme ones are not. This means that parts of many sites can be impossible to reach – for example at http://www.crowncourtchurch.org.uk/

I have read some comments from blind users very recently that putting the title attribute on text links as a matter of course is an annoying feature of many sites – including many (most) WP sites (including my own admittedly). The issue is that the title attribute is read out by screen readers as well as the link text. Perhaps there could be an easy option to suppress that in WP menus?

Hope this helps.
Graham

About

Welcome to the official blog for the WordPress accessibility group - dedicated to improving accessibility in core WordPress and related projects.