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: http://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.
Bob Easton, 
Chuck Reynolds 12:33 am on May 6, 2011 Permalink
I still really dislike the big circle comment count thing…
in /themes.php?page=custom-header the header image at top shows as a broken image. source shows
On single posts, the entry-content seems like there’s too much padding on top… the separation from the h1 to the post content is a pretty big gap.
I’ll mess with it more later. nav and search expanding seem fine – tried to break that but seems alright.
Jane Wells 12:53 am on May 6, 2011 Permalink
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.
Barry Johnson 1:37 am on May 6, 2011 Permalink
Accessibilty Specialist. Federal 508 SME
Jane Wells 5:00 pm on May 6, 2011 Permalink
Hi Barry. Can you tell us a little more about your professional background? Google is not being helpful.
Bidhan Adhikary 4:01 am on May 6, 2011 Permalink
Hello, I am a technology blogger. I would like to be a part of the new accessibility group.
Jane Wells 4:52 pm on May 6, 2011 Permalink
Hi Bidhan. Thanks for your interest. Do you have experience as an accessibility professional? That’s really what we’re looking for in this group.
Tady Walsh 8:49 am on May 6, 2011 Permalink
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?
Cheers…
Tady Walsh 10:08 am on May 6, 2011 Permalink
Ok guys, had a quick review of the code there.
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.
Jane Wells 3:39 pm on May 6, 2011 Permalink
Thanks for the helpful feedback! Will try to get tickets started for these things asap. And yes, we would like the back end to be accessible.
Mark Jaquith 3:56 pm on May 6, 2011 Permalink
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.
Tady Walsh 4:25 pm on May 6, 2011 Permalink
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.
Sylvia Egger 10:28 am on May 6, 2011 Permalink
Using WordPress for many years I decided last year to make WP default theme Twenty Ten more accessible with a child theme (Accessible Twenty Ten): http://accessible.sprungmarker.de/2011/01/accessible-1-0/
I also made the html5 default theme Twenty Ten Five more accessible (http://accessible.sprungmarker.de/2011/04/accessible-five/).
My special accessibility interest is of course the WordPress front end, but I also try to get WP editor more accessible developing plugins as MCE Accessible Language Change (http://wordpress.org/extend/plugins/mce-accessible-language-change/) which makes it easy to integrate language change in the content of the editor.
I would wish to contribute in WordPress accessibility, especially in developing the new default theme more accessible than Twenty Ten.
Would be great and I am glad that WordPress developers now will have a stronger focus on accessibility.
Sylvia Egger
@sprungmarkers
Keith Hinton 10:41 am on May 6, 2011 Permalink
Hi folks.
Just a point.
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.
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!
Ian Stewart 2:51 pm on May 6, 2011 Permalink
Hi, Kieth. Until you’re set up with an installation of WordPress trunk for testing we have a demo site for testing Twenty Eleven that we’re setting up at
http://twentyelevendemo.wordpress.com/
Tady Walsh 10:51 am on May 6, 2011 Permalink
Typical! Should have read that properly. I misread “leave your info” as, leave your info about the accessibility of the theme.
Gimme a shout if I can be of more assistance. @tadywankenobi
Azizur Rahman 12:23 pm on May 6, 2011 Permalink
I have found one issue. you got my email and I am on twitter @azizur
esmi 3:15 pm on May 6, 2011 Permalink
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”.
Jane Wells 3:38 pm on May 6, 2011 Permalink
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.
esmi 2:31 pm on May 19, 2011 Permalink
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:
http://blackwidows.co.uk/blog/2006/10/16/designing-for-dyslexics/
Jane Wells 3:47 pm on May 6, 2011 Permalink
@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?
Tady Walsh 4:21 pm on May 6, 2011 Permalink
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.
Hope this helps…
Jane Wells 4:24 pm on May 6, 2011 Permalink
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).
Tady Walsh 4:28 pm on May 6, 2011 Permalink
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.
Tady Walsh 4:31 pm on May 6, 2011 Permalink
Here you go, this looks pretty helpful:
http://books.google.com/books?id=u9zFGT8GrV4C&pg=PA475&lpg=PA475&dq=text+foreground+background+color+dyslexia&source=bl&ots=HqhE7Lbfd2&sig=C8FlPTHEBj66D61eY1kwW5uxOw8&hl=en&ei=8iHETYu4BMGHhQeY5eWIBA&sa=X&oi=book_result&ct=result&resnum=4&ved=0CDQQ6AEwAw#v=onepage&q=text%20foreground%20background%20color%20dyslexia&f=false
esmi 2:26 pm on May 19, 2011 Permalink
Sorry for the slow response. Been semi laid-up recently. The information I have came from some research I carried out about 4 years ago on contrasts generally (I was looking at scoptic sensitivity & dyslexia particularly) . Check out the comments from Pat Rees on http://blackwidows.co.uk/blog/2006/10/03/does-w3c-get-its-contrasts-wrong/
John Brandt 4:07 pm on May 6, 2011 Permalink
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.
John Brandt
Sylvia Egger 9:56 pm on May 6, 2011 Permalink
Hi – I checked your demo site and my own installation on a11y issues:
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
If you get further to level AAA you can add image caption text, comments header text, footer text colophon, default widget titles grey, article post meta grey, comments headline etc.
I tested only the light version so far …
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
this is a really nice thing, but one has to remember what the field is for and if it is required.
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.
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
5. Zooming: I tested page zoom and text zoom separately
Also IE9 does not zoom the text in pixel – so it would be better to make text via css more flexibel.
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 …
Unfortunately there is up till now no possibility to add alternative text to the header images …
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.
So – this was a quick review and for a more detailed analyses I have to have more time.
Hope this helps and greetings from cologne germany,
Sylvia Egger
http://accessible.sprungmarker.de
@sprungmarkers
ramseyp 12:33 am on May 9, 2011 Permalink
Hi all,
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.
Cheers!
Dominik Paszkiewicz 6:37 am on May 12, 2011 Permalink
Hi Jane and all,
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.
I’d like to be added to the group focusing on accessibility.
All the best,
Dominik
Jeffrey K 2:00 pm on May 12, 2011 Permalink
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/.
Jeff K.S.
Felipe 1:47 pm on May 15, 2011 Permalink
Hi,
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?
Bob Easton 10:57 am on June 19, 2011 Permalink
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: http://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.
Graham Armfield 6:10 am on July 2, 2011 Permalink
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/
It is possible to do accessible flyout menus. Have a look at: http://www.diggersworld.net/ which is built using WP.
Use of Title attribute.
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