Support Requests
If you post a comment here looking for support regarding your own site, it will be deleted. If you need support, please post on the wordpress.org support forums.
Thank you.
Recent Updates Toggle Comment Threads | Keyboard Shortcuts
-
esmi
-
esmi
Site Feedback Request
We have been approached by the folks over at translate.wordpress.org. They are keen to ensure that it is accessible as possible and would like our help to identify any problems with the current site.
So please take a little time, between May 17 & May 31, to have a look at translate.wordpress.org and give us your feedback via comments on this post. In order to support you and provide some structure to the feedback, we’ve prepared a Site Feedback Guide that should help.
We look forward to your contributions.
-
Lauren
-
seablackwithink
Readability
the homepage, Projects for the Getting Started Guide as the heading, including link to the guide….then maybe space above and/ or below the links.
summary for each project and the Getting Started Guide can be inserted for educating the users about the products before clicking.
Add users guide /explanation link
Accessibility:
Every link needs at least a description “Project: ____ is not enough description if I do not know what project____ is, possibly, add a guide about the layout explaining that the left column is a list of sub-projects and the right column is the list of translations.
-
-
esmi
IRC Meetings
Just a quick post to remind everyone that we are still holding a weekly IRC meeting in #wordpress-ui every Wednesday at 19:00 UTC.
The meeting on May 1 covered the variations in form handling across different screen readers as well as a recent issue reported with the Jetpack plugin. As a result of the latter discussion, we now have a representative on the Jetpack Beta Group and Trac ticket #1710 has been created.
#wordpress-ui log for May 1, 2013.
On the May 8 meeting, discussion centred on the draft Site Feedback Guide. The guide is intended to both add structure to any site feedback as well as provide some support for non-technical disabled users who would like to join in. We hope to test the guide out later this month.
-
Graham Armfield
Sorry I wasn’t able to make the meeting.
-
ceo
Likewise. I should be around next week, though.
-
-
esmi
No problem. I think everyone was rather busy this week but at least we got a chance to go through the new site feed back guide.
-
-
esmi
IRC Meeting: April 24, 2013
We had another lively IRC meeting on Wednesday.
3.6 Post Formats
It was previously decided that both the video and audio post formats could benefit from an ability to add links to captions (for videos) or transcripts (for audio files) and some preliminary investigations were started to look at the possibility of submitting patches. However, as there has been some concern about the release schedule for 3.6 and the possibility that Post Formats might be removed from the release, this has been shelved until we hear further.
-
Andrew Nacin
Post titles in attributes
In pretty much every theme, there is something that looks like this:
<a href="<?php the_permalink(); ?>" title="<?php echo esc_attr( sprintf( __( 'Permalink to %s', 'twentythirteen' ), the_title_attribute( 'echo=0' ) ) ); ?>" rel="bookmark"><?php the_title(); ?></a>
My question: Is “Permalink to (title of post)” a WordPress anachronism that, by being a redundant title attribute, actually harms accessibility?
-
Joe Dolson
Yes, that is generally not helpful to accessibility. The amount of harm is relatively slight (that vast number of title attributes in nav menus is a greater issue), but it is definitely an anachronistic model that causes minor accessibility issues.
Essentially, any case where the title attribute is the same as the link text, it is redundant at best, and causes a repetition effect (where screen readers read the text twice) at worst.
-
Graham Armfield
I agree with Joe.
-
Lance Willett
Note that not all themes duplicate the post title—for example, in Twenty Thirteen we use this format for title text to go along with anchors where the anchor text is the post date, and in that case it’s very important for usability and accessibility both.
-
Joe Dolson
Yes – but that’s a different use case, where the anchor text *does not* match the title attribute. In that case, the problem is that the title attribute will usually not be available to users of assistive technology, because title attributes are not exposed by default in most non-mouse-based contexts.
This is also the reason that the title attribute problem is relatively minor — title attributes are only perceived by a screen reader user if a user is using verbose settings for reading those attributes, which, due to the fact that title attributes are, on the whole, not usually helpful, is commonly disabled.
-
-
esmi
It’s also of absolutely no use to sighted keyboard navigators. Given that some of these users will be dyslexics using screen readers, it may well be that the announcement of the title attribute will be causing more harm than good. I’d argue that, as a very general rule of thumb, if it’s important enough to be added to a page, it should be added in clear text. If it’s not that important, why bother adding it anyway?
-
ryanve
-
joe
Although Joe Dolson is right, that it has minimal effect, I think esmi raises a good point in that anything that requires mouse activity to expose, and that exposure is important, it should be surfaced in a more inclusive manner.
-
-
Joe Dolson
Just submitted: http://core.trac.wordpress.org/ticket/24148. Comments welcome.
-
_Redd
I never cease to be amazed, Joe, thank you–yet again.
I looked briefly at the ticket, and I see obenland has the following question:
Do we really need additional html elements for the ids? Can’t the labels or the p elements carry them with the same effect?
My understanding is that ARIA is needed above and beyond simple form labeling and p elements due to the dynamic nature of WordPress. In other words, if a page is updated dynamically for whatever reason, the screen reader will only capture the “old” information in the buffer, without ARIA…
Is the following a true and correct statement?
To create a “live” region by which screenreaders may be able to access dynamically updated pages (such as those used in WordPress) using the aria-live property is necessary–simple form elements won’t do.
Thanks for any input you may have, and thanks again, VERY much, for what you do.
-
Joe Dolson
First, this is *not* creating a live region — the native comment form is not a dynamically updated region; although some themes may cause it to be. What this patch is about is incorporating the extra text statements that are contained within the comment form into the labels for the elements that they are associated with using ARIA, so that text is exposed to a screen reader without requiring a second pass through the form.
The commenter is correct that an extra HTML element is not required in order to attach these IDs; and I was able to eliminate two of them, because the text they’re catching is already wrapped in entirety. A third span is required because the text I needed to catch is not already discretely wrapped by any element.
Your statement is accurate, yes — but not actually relevant to this situation.
-
_Redd
Once again, then, thank you! Much appreciated.
-
-
-
andyvaughn
Thanks for the thorough look at this, Joe.
Perhaps this is forest-questioning in a tree-analysis area…but, is it semantically appropriate to be using paragraph-tags for comment-form-email, comment-form-comment, and comment-notes? I always rewrite my comment templates to definition lists, with labels as definition-titles, and inputs/textareas as definition-descriptions, as I felt this was more semantically correct. Am I incorrect? Does this have a negative effect when read as a definition-list? It’s been a while since I’ve used a screen reader.
Either way, thanks for the work Joe. -
esmi
I don’t think there’s a problem – semantically – with either approach and there are valid arguments for both. From a Real Life accessibility perspective, it might be worth bearing on mind that some (most?) screen reading software will announce content in definition lists in the same manner as content in paragraph tags. So from the user’s perspective, there’s no difference and your definition lists will still work just fine.
-
andyvaughn
Thanks for the quick reply, Esmi. It helps to know I’m not causing screen-reader confusion with my preferred form markup.
-
-
Joe Dolson
I’d agree with esmi on this; there may be some semantic value to considering these to be definition lists (although it’s debatable), but there is no accessibility value. It would just be a matter of your own judgement concerning whether the list of inputs should be considered a set of term/definition value pairs. My feeling is that the
Either way, it doesn’t impact accessibility.
-
Anders Herning
Awesome work Joe! Really appriciate it! I know it’s not the right approach, but I gotta ask:
I’ve been searching for the most “popular” accessibility theme for WordPress but can’t seem to find any.
Do you have any advice on this?-
esmi
Not at this time – no.
-
-
-
Joe Dolson
Updated Theme Review Guidelines
I’ve updated the Theme Review guidelines for Accessibility again. This update takes into a consideration a number of suggestions and questions from Chip Bennett regarding the understanding of issues and how to resolve them.
Among the changes:
- Images now state that decorative images must be included with CSS.
- Headings explicitly states that post and widget titles must be wrapped in headings, to draw the ‘reasonable headings’ guidelines into a context explicitly relevant to WordPress structure as defined by a theme.
- Link text provides specific techniques for accomplishing the goal.
- Keyboard navigation provides guidance on testing and specific mention of one of the most common failures for dropdown menus.
- Contrast references tools for testing.
- Skip links defines a conforming skip link.
- Forms defines specific changes that can be made to defaults that would break accessibility.
Your comments are welcome.
-
Joseph Karr O'Connor
This is looking very good now, thanks for all your work on it. I especially like the low-key approach to ARIA.
seablackwithink and 
Lauren are discussing. 
_Redd, and 2 others are discussing. 
Graham Armfield
Accessibility IRC Chat – 3rd April 2013
A few of us took part in the IRC chat yesterday (see transcript here). Not surprisingly the main subject was the Add Media Panel accessibility, and the format of the chat turned into a live screen reader test on the functionality performed by @_Redd and @arush (and myself).
@lessbloat had kindly had a go at implementing my quick and dirty pragmatic ARIA solution – for which we are truly grateful. Once we’d got access to an environment where the changes were in effect we could see that vast improvements had been made to the accessibility.
I’ll save the detail to the blog post about Add Media Panel but to summarise:
- Keyboard-only users can now tab through the items in the media list and select/deselect using Enter key
- Screen reader users were getting some useful information but possibly only the newest versions can fully use this functionality.
- Voice recognition users can at least use the tab commands to move around the list and select them.
The key decision now is whether the functionality is useful and solid enough to include in 3.6. A couple of extra enhancements would make the solution better for screen reader users – once again see previous post.
My vote would be to run with it if we can get the small further enhancements. We can hopefully address the rest of the accessibility issues within 3.7. But what do you think?
-
_Redd
RUN WITH IT! Enhancements are for plugins!!!
-
Joe Dolson
This is great Graham. I’d agree with _Redd – this sounds like a great improvement. I don’t see any reason to wait for perfection; this is an important step forward.
-
_Redd
I have the 3.6 beta up, and, as one who is ignorant of screen readers, I can at least say that my version of NVDA announces itself nicely in the Add Media area. Thank you, Graham and lessbloat, this is a jaw-dropping leap forward!
Joe Dolson
I’ve been chatting with Chip Bennett via the Theme Review list about the Theme Audit guidelines. With his feedback (which was from the theme author and reviewer perspective, and very valuable) and the feedback from the comments on my previous post, I’ll be working on the next version with a variety of changes of various types. He’s going to be proposing some changes to the general guidelines that will obviate the need for a couple of the elements in the accessibility audit guidelines.
joe
I think it would be worthwhile to still mention the accessibility guidelines anyway, perhaps a cross reference or state that it also satisfies accessibility points.
Graham Armfield
Add Media Panel and WordPress 3.6 – A Simple Solution?
The beta version of WordPress 3.6 is very close now and the chances of significant extra functionality being included must be slim. But, the Add Media Panel introduced in 3.5 is still inaccessible and the trac tickets raised on this are still untouched.
This is a real problem as the Add Media Panel is such a key piece of functionality.
However, from our IRC chat yesterday the germs of a simple solution may have emerged – a solution that could maybe make the functionality accessible to keyboard and screen reader users. We just need someone to give it a try.
-
_Redd
Just to THANK you for the amazing work that went into this…..the path you’ve outlined here gives us a real way to pursue this, and to help out. More to come, but again, thank you!
-
Joe Dolson
This is a great suggestion — and should be very simple to tackle.
Do you think that the img should also use the aria-labeledby attribute to associate the label? I haven’t tested this, but I’m not sure offhand what behavior is exhibited by a screen reader in associating a label with a non-form field by ID.
-
GrahamArmfield
I had thought about that Joe and it may be a better solution. The code I propose was based on an example within that Mozilla site, but the working example they link to did it using a different technique.
One of the things I was keen to avoid was ‘double voicing’ by screen readers that I know can be annoying – hence the blank alt attribute too.
I guess the key thing is to find someone who can prototype this like @lessbloat did with the Custom Menu solution. We can then test it with various AT.
-
-
Tony Scott
Great work Graham – many thanks!
GrahamArmfield
There has been some action on this issue. See the discussion and revised proposal on trac #23560.
-
_Redd
Graham, what you and lessbloat have done on ticket #23560 is nothing short of amazing, absolutely amazing.
Do I understand that there’s a possibility this can go into 3.6?
Are you going to be able to make it to the IRC chat today?
-
Graham Armfield
I’m really hoping we can get this into 3.6 with @lessbloat’s help. It doesn’t address all the potential accessibility issues but at least it’s going to be a lot more accessible than it is now.
Yes, I’m intending to be in IRC chat later.
-
_Redd
When I last saw the ticket, you still hadn’t been able to have one to test. I can’t “see” the ticket now, so I don’t know if you’ve been able to test. As a person who is really, really stupid to this, I tried to incorporate his diffs into my 3.6 alpha test site….would you like to get into it to look around?
I don’t know enough about screenreaders to even approach this…
No promises that I did anything right, but due to the time crunch, I’m offering it to you for screenreader evaluation….
-
_Redd
Looks like I set up the hyperlink wrong
http://red-hound.com/test/addmedia/
Let me know if you want to get in there, I know EVERYONE is short on time….
-
Graham Armfield
That would be superb if you could let me have access to the site. Please email me the logon details – graham.armfield@coolfields.co.uk and I’ll give it a go.
One day I’ll have to see if I can get a suitable environment together but it’s a little daunting from a standing start.
-
_Redd
Coming your way, standby
-
_Redd
You should have an email from me….when I tried to create you as a user and give you a password, it said the name was reserved….I think it is waiting for your confirmation email….let me know how it goes,
-
Graham Armfield
OK I’m in. Will test shortly.
-
_Redd
Hi Graham, I’ve redone the media-views.js file, and it is yours to test. I sent you email with a file called “modified-media-views.js” so you can double check it if you like. Not sure if your spam folder will kick it back.
I’m watching for your response with baited breath!
-
_Redd
OK, thank you Graham, at least, know that you have a server to play with. We’ll work it out. I’ll see you on the IRC chat.
-
-
-
-
Graham Armfield
@lessbloat has made some further changes after our testing yesterday which have further contributed to the accessibility.
It is now possible to select/deselct with the space bar as well as the Enter key. This should enable (hopefully) all screen reader users to select the items as if they were checkboxes – without having to rely on the ‘pass-through’ keystrokes.
Also, he has improved the visibility of keyboard focus on the media files so that anyone using keyboard, or voice recognition users emulating tabbing will be easily able to see where they are.
Within the trac ticket #23560 I have asked him to make one further change – that is to place the image title within the aria-label attribute rather than the file name. That way, if you’ve given the file a meaningful title or alternate text when the file was first uploaded it will be presented to the screen reader.
So far, comments received have indicated in favour of getting these changes included within 3.6. I’m not sure how this is achieved – is it automatic, or is there a further process that needs to occur.
If anyone has objections then now is the time to express them I guess.
_Redd
Only writing here to say we can’t thank the two of you (lessbloat and yourself) enough. This is mind-blowing! What a huge accomplishment!
Readability:
For the homepage, I recommend a section similar to Projects for the Getting Started Guide as the heading, including link to the guide. For the link list, I also recommend space above and/ or below the links.
Maybe, a brief introduction or summary for each project and the Getting Started Guide can be inserted for educating the users about the products before clicking.
Also, there isn’t a search tool or a privacy policy link/document on homepage.
Accessibility:
Every link needs at least a description, or more information about what it is. For example, alternate text, “Project: bbPress” is not enough description if I do not know what bbPress is. How will I know to click on it?
When I click on bbPress or any other link, it opens to a dashboard-like page. Maybe, there should be a guide also about the layout explaining that the left column is a list of sub-projects and the right column is the list of translations in progress. Also, this guide can explain the attributes in the table.
Hope this helps,
Lauren