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
IRC Meeting: May 22, 2013
Another small but busy IRC meeting on #wordpress-ui where discussion focused on assessing the translate.wordpress.org site for possible accessibility issues.
If you have a little spare time, please do try to contribute to the site feedback request. Any observation — no matter how small — is valuable. If you need some ideas on what to look for, please check out our Site Feedback Guide.
-
flick
-
esmi
GlotPress is just a name — like WordPress, or BuddyPress. I think the problem we have here is that 3 different — but related — resources are all called “GlotPress”.
Glad to hear that the IRC log was useful. We’d be more than happy for you to join in the meetups at any time.
-
Marko Heijnen
This hopefully will get change really soon
-
-
-
flick
@esmi: Thank you for the welcome and for the clarification. I will be sure to try and attend an #irc meet up soon – just need to remember to put it into my Google calendar and be in
-
TDM
Any idea when the next one will be ?
-
esmi
Tomorrow – 19:00 UTC in #wordpress-ui
-
-
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
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 -
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
The following is the result of a fairly cursory audit of the site for potential accessibility issues. I did not attempt to differentiate what issues were generated from user-added content and what issues might be present in the GlotPress application itself. If you have any further questions or I can help in any way longer term, please let me know.
Markup
In general, the HTML markup is solid with good use made of list tags. Where it does breakdown is when you get into individual project translation tables (example table). As these are fairly complex data tables, I feel that it’s essential to ensure that best use is made ofidfor table headings and theheadersattribute for individual cells. This should allow assistive technology software to render the tables in a far more meaningful manner as well as allowing disabled users to move around the tables far more effectively. Two excellent resources on this subject are Making Tables More Accessible With HTML5 and Accessible Data Tables.Contrasts
On pages like Projects → WordPress, the contrast for the (definition) description of each sub-project is far too low at only 3.5:1. Even I’m straining to read it. It needs to be increased to at least 4.5:1 (try#777).Readability
Generally speaking, I’d like to see an increase in the text sizes. A body font size of only 14px is a little on the small side. In some areas — such as the descriptions for each sub-project on the individual project pages — the text really is becoming hard to read without using Zoom.User Support
When you first hit the site’s front page, there is an overwhelming feeling of “Where am I? What’s this all about?”. The site really doesn’t explain it’s purpose upfront, so it’s easy to imagine many users being somewhat bewildered and unsure of where to go next. Some of the initial content from Getting Started with translate.wordpress.org could really be moved from that page and placed at the top of the site’s front page to clearly establish the site’s purpose.Navigation
This site really doesn’t have an effective navigation system. Instead, a breadcrumb is used in place of a more standard navigation menu. Whilst this is functional, it does force users to navigate to and from the site’s front page all of the time — which could impose an unnecessary burden on some keyboard navigators. I also noted that there is no way to skip this breadcrumb/navigation menu when entering a new page. Yet another issue for keyboard navigators.Some disabled users also rely on the title tag (as displayed in the browser tab) for primary navigation. Once you drill down into sub-sub-projects, this tag uses text like “3.5.x < GlotPress" — which isn't exactly informative. 3.5.x of what? In other areas, the title is far more helpful — "Translations < Dutch < Twenty Twelve < GlotPress". At the risk of increasing redundancy, perhaps a solution to this would be to re-address the headings on (for example) the WordPress project page, so that they used a “WordPress 3.5.x” format? This should create page title along the lines of “WordPress 3.5.x < GlotPress".
And Finally…
There's the issue of the site's name — GlotPress. A name also shared by an official wordpress.org blog and the open source content management application being used to generate content on translate.wordpress.org. I’ve left this until last because I feel that this definitely overlaps into usability but could still impact heavily on some disabled users groups. If I link to GlotPress, which of the three resources am I linking to? If you cannot tell without clicking the link, then we have a problem. I’d like to see each of these resources use their own unique names. Perhaps translate.wordpress.org (currently the only way I can clearly reference a specific resource) could be renamed “WordPress Translate”? -
flick
I would also like to put in my tuppence to second/third that it would be great to have a short introduction to the project(s) on the main page of Translate, rather than having to click through to the next section.
And although it became obvious (a few seconds later) that one should click on the headings of e.g. http://translate.wordpress.org/projects/wp/dev to sort the data, perhaps it may be helpful to have arrows as a visual guide?
Thanks
-
_Redd
First of all, absolute hats off to the team at wordpress.translate.org for doing this. This is a really, really great thing, and no small feat to accomplish. Thank you.
1. Getting Started with translate.wordpress.org
Logical page order, with appropriate h-level headings. Easy to read text as far as color contrast, and font size were concerned. However, navigation in and out of the page wasn’t obvious, and could perhaps be strengthened. The “logo” for GLOTPRESS was great for returning home, and at least the alt tag announced it’s URL as http://translate.wordpress.org. A bit of “renaming” links may help with navigation. For example, The name of GLOTPRESS with a link to translate.wordpress.org led to a little confusion for me, and the links at the top, next to the login link titled, “Need Help?” was a dead-end link to the page I was already on. I had not expected this, as the title of the page was “Getting Started…”, and I would not have expected a hyperlink to a page I was already on. Elsewhere in the site, this was not done, so the lack of consistency would also contribute to a bit of confusion about linked areas.2. Projects Page
Very clear, easy to understand.3. Sub-projects Page (Glotpress) This was difficult to read, mainly due to low contrast of the color choice of the text, and of the font size, which was small. Personally, I was unable to read it. When using NVDA screenreader, it read “Development” as a list with two items in it, but never read the two items.
4.Development PageThis was listed as active, but when I went to this page, it said that it had no translations. I was a little confused at first, and figured out the sense of what was meant. That said, a revisit to the terminology used for an active page with no translations may help alleviate some confusion.
5. WordPress subprojectNVDA screenreader announced that “Development” was a list with fourteen items, but I never heard the items announced.
6.Development GuideVisually speaking, very easy to understand. Using a screen reader, it was easy to follow once I was inside the table, as the headings were announced, and the logic went across rows (kudos) but getting to and from the table was difficult. At one point, I tried to go back over the page by simply going to the “hide” link, just as a way to get back to the top of the page. When I did so, the “hide” link faded away, and I couldn’t get it back. Then I was really stuck in the table with no way to navigate around on the page via the screenreader (please note, I am a sighted user….another user familiar with a screen reader would have probably known how to exit out of the table much more easily than me–but I never figured out how to get to the small menu on the left hand side for the different themes).
7.Translation of Chinese (Taiwan)Visually speaking, very well organized. There were some gray boxes with no corresponding legend on the bottom of the page, which I think would have helped. For example, the words “post revision title extra” was in a gray box, and in order to understand why it was cued that way, I looked at the bottom of the page at the legend, which had a green, orange, yellow, pink, and striped code, but no gray code. Consider, for the sake of consistency, when text is color-coded, to include the meanings behind the color-coding consistently. As far as the faint words, “Double click to add”, I almost didn’t see them (but the screen reader read them just fine). When I double-clicked within, just to see what followed, I tried to get out of it using the back button (a common behavior) and I was taken out, all the way back to the Development main index page, rather than back to the page before, the Translation of Chinese page. The same problem happened when I had hit one of the “details” links within one of the rows.
8.Translation of Chinese (Taiwan) in Chinese mode for NVDA the screen reader only reads the links at the top of the page, then the table headers, and from there, only the “Details” column. It doesn’t tab over to the text. Using the mouse, I was able to click on the sixth row down, to the Chinese, and listen to the screenreader announce the contents in Chinese, but I relied on sight and a computer mouse to get there.
I just have to say, I am in awe. This is an amazing project, just amazing. Thank you so much for what you’re doing here; it’s really appreciated, and it’s going to make a difference to so many people. Thanks again.
-
_Redd
One other item I forgot to mention, is that when using colors to code, if you could, please, use colors that are very distinct from one another in terms of lightness or darkness. A color-blind person would not have been able to tell the light green, from the pink. etc. Consider a visual coding system that is independent of color. Again, though, thank you for this amazing, awesome project!
-
-
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.
_Redd, 
_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.
Thank you for the log. Am only just beginning to get acquainted with the Accessibility side of WP so every little helps. I am confused by the naming of GlotPress but perhaps it could be because I haven’t read enough about it. Is there a glossary somewhere one can refer to? Thanks.