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
Title Attributes Galore
The patches for Trac ticket 24766 are slated for addition to WordPress 3.7. This is great news for assistive technology users who have been forced to wade through a sea of unnecessary title attribute verbiage. But we need to ensue that the patches cover all unnecessary title attributes and that those deliberately excluded from the patches do not present any accessibility issues.
Currently, the excluded methods, functions and scripts are:
the_author_posts_link()- rss.php
wp_fullscreen_html()get_adjacent_post_rel_link()_walk_bookmarks()get_image_tag()the_shortlink()
-
David A. Kennedy
-
Amy Hendrix (sabreuse)
Both of those functions are included in the patch that’s currently on the ticket — you can see the full list at the ticket link.
The list in this post is just the ones that I left off the patch, either because they’re deprecated functions (which means aren’t actually used in core anywhere, and we normally wouldn’t make any changes to them unless it was for something like security), or because the title attributes are being used for help and not just labels (and in that case, they should get a better solution rather than just being deleted without any kind of fallback).
It’s definitely not a problem to get this batch in, and still pick up any that were missed in subsequent patches.
-
esmi
Understood, But my concern is how to handle wp_fullscreen_html()
-
Amy Hendrix (sabreuse)
Yep, got that — I was just trying to answer David’s question about other functions that didn’t appear in this post.
On with the wp_fullscreen_html() discussion, which is definitely a tougher case than most of these!
-
-
-
-
Joe Dolson
I think we need to consider some alternatives for the wp_fullscreen_html labels and interface generally — this is definitely not a simple case of removing the title attributes alone. It should probably be pushed as a separate ticket; it’s related, but it seems sufficiently different that treating it independently is worth while. Thoughts on that?
-
esmi
I agree. This needs to be treated as a separate ticket.
-
-
esmi
IRC Meeting: August 7, 2013
A very busy & productive meeting. We’ve identified two high priority areas that we’d like to focus on in the next couple of months.
-
esmi
Accessible Polls and Surveys
We are always looking at ways to increase feedback from disabled users of WordPress. The more we know about the issues that people face every day, the more we can advocate for positive changes.
We also appreciate that it can be very daunting to post a comment on a blog like this one. So we would like to look at using short surveys and simple polls as a way of allowing people to give us their feedback as simply and as easily as possible. That, however, raises a whole new set of potential problems. We need to ensure that whatever tools we do use are as accessible as possible.
This where you come in.
Please tell us about any accessible survey and poll applications that you know of.
-
jebswebs
I like SurveyGizmo. They were the first to make their survey tools accessible long before any of the others even knew what accessibility meant. They have several templates that are designed specifically for accessibility and some decent mobile templates as well.
-
After Gadget
I can’t think of any survey tools that are particularly accessible. The one I’ve used the most is survey monkey, and I couldn’t seem to make it work with Dragon, though I was much less proficient at Dragon at the time, so maybe it is actually better than I think. I had to fill it out though because it was the Census. But I did want to let you know that I am happy to fill out whatever survey you come up with.
mouse window -
_Redd
@After Gadget That would be AWESOME help! Thank you SO much!
-
-
esmi
IRC Meeting: July 17, 2013
Long time no meetup update! Our regular IRC meetings have still been taking place every Wednesday at 19:00 UTC But we’ve been so busy that it’s been hard to stop and provide updates.
Last night’s meeting focused on how to gain a better insight into the real problems that some WordPress users face every day. We also discussed ways to increase the flow of information from those users so that we can advocate high priority changes on their behalf. We’ll be posting about some of our ideas and asking for your help shortly.
-
_Redd
As usual, another great meeting. Thank you so much for everything you do.
In reference to what was discussed last night, I came across this survey from Adobe on screen design that I thought might be a good model to start. I don’t know how “accessible” it is yet, but we can find out!
-
-
Graham Armfield
Accessibility Objectives for WordPress – Initial Thoughts
Some of us have been talking recently about pulling together some accessibility objectives for WordPress. These are things that we feel could, or should, be happening to ensure that the profile of accessibility is enhanced with the WordPress community.
Ultimately, in order to support Matt Mullenweg’s view on the democratisation of the web by web-related software we want as many WordPress websites as possible to be accessible to as many people as possible. We also need to ensure that the WordPress admin screens are not excluding certain user groups from key parts of functionality.
With that in mind, here is our initial list of objectives. Please feel free to comment on these, and to suggest others that you think are also important.
-
_Redd
Great list, and provides a great map for a path forward. Huge thanks for putting this together.
Regarding,
Development of formal education and outreach programs
So that all WordPress core developers can gain a deeper understanding of the range of issues faced by disabled and elderly users.
I personally don’t think this should be directed only at core developers, or even mainly at core developers. It should be much broader, so that those who support the supporters are educated. For a real-life example, take the instance in which a manager instructed that the words “text size” small, medium, and large from the web page because it interfered with design, or made color choices that would have made it impossible for those with color-blindness to actually read the web page. The outreach should extend not only to those who code or design, but to those who manage, approve, fund, or are otherwise beholden to the creation that is a web page. If managers understood the impact of their decisions, then that alone would enable designers to build accessible features even at the most basic level.
Thanks again for what you’re doing here.
-
_Redd
A couple more things to add.
1. In the “providing resources” section, what’s the possibility of actually creating a new, accessibility forum in the support forums?
2. I don’t know how to categorize this, but is it possible to visit “how” accessible themes are made available through WordPress.com and WordPress.org theme search? . I understand the “accessible-ready” tag is a seal of approval, but I’m concerned that the tag may be unfamiliar to a casual user. Perhaps, if we could find out how a casual user searches for such themes (I’m guessing accessible, or accessibility, or a11y) then we could make a point to include those tags so the themes come up better in searches. Right now, for what ever reason, it’s not easy to find them.
Also, what’s the possibility of adding a pointer to accessible themes from this blog, or some highly visible location?
Thanks again!
-
Joe Dolson
The visibility of accessible themes in the WordPress.org theme search is essentially non-existent, as it stands. The theme repository has a controlled tag structure: only the tags listed on the tag filter (http://wordpress.org/themes/tag-filter/) are allowed – there are no tags in the directory not on that list.
So, we can’t just add random tags; every tag needs to be a unique way of associating that particular characteristic of a theme.
We can encourage people to use whatever accessibility terminology they choose in their description of the theme; but the “accessibility-ready” tag would still be the only one of definitively pulling up all themes that include that characteristic.
I’m not sure that the theme search tool is actually all that heavily used; but I don’t really know that. I’ve never used it other than to try and identify accessible themes; searching all terms I could think of.
-
_Redd
Thankyou (as always!) Joe.
Let me try to amplify my remarks a little, because I’m not trying to remove the “accessibility-ready” tag from the equation. Not at all. I just think we should be adding additional tags to address the common way in which people search.
I guess at the heart of it, I ‘m unsure why adding “random” tags is in conflict with the need to have a unique identifier. The unique identifier of “accessibility-ready” is a seal of approval, and we should “market” it that way. But to FIND accessible themes is something else. Additional tags relative to accessibility would help those themes surface. In my mind, it’s no different than having a unique web-site, and using multiple meta-tags in the header for SEO purposes, or to assist in search, or in using #accessibility and #a11y in Twitter, yet having only one, authoritative Twitter site for the WordPress accessibility group.
For the particular case where someone is logged into WordPress, and searches for a new theme, they go to the page tab, “Install Themes”. The first way they’ll look for the theme is through a keyword search, so the addtional meta-tags of accessibility, a11y, etc. would help there. But the next place they’ll look is the “Feature Filter”—they have themes organized by colors, columns, etc. Can we coordinate with whomever develops the interface so that we could have a section labeled, “accessibility-ready”, or “accessible”, or something like that?
I hope I’m making sense. At any rate, thanks again, and I’m always looking forward to whatever further input you may have on the matter. Take care.
-
esmi
I ‘m unsure why adding “random” tags is in conflict with the need to have a unique identifier.
Because the whole theme repo system relies on a limited set pre-defined tags. Throwing it open to random tags would stop that system working effectively.
Can we coordinate with whomever develops the interface so that we could have a section labeled, “accessibility-ready”, or “accessible”, or something like that?
We already have someone. Well… two someones actually. Myself and Joe D. We both discussed this at length with the rest of the theme review team (who have been tremendously supportive). In order to develop an a11y audit that would work within the overall theme review system, we needed to come up with a single tag that didn’t “over-promise”. Tagging a theme as “accessible” was quickly dropped as – in reality – there is no such thing. A theme can only facilitate the creation of an accessible site. It is not “accessible” within itself. The tag “accessibility-ready” seemed to be the best option and the tag will be added as an option to the theme tag filter once the auditing process is fully up & running.
-
_Redd
Thank you, much appreciated. I see I was ignorant of the mechanics of theme “tagging” in WordPress.
And, if the accessibility-ready tag will be added to theme tag filter once the auditing process is up and running, then that fact alone will make the accessible themes more visible.
Best regards, as always!
-
Aaron Jorbin
Regarding appointing an accessibility lead, I’m going to strongly disagree with that. We are going to have much more success in the long run with WordPress if it’s not one person’s responsibility, but instead if everyone takes responsibility for it.
I strongly support developing some common educational materials. Joe – I would love to see your slides from WCCHi converted into an accessible HTML slideshow and put up on github where others can contribute. We can then advocate that others use this base slideshow and present it at WordPress (and other) meetups around the world.
-
Joe Dolson
I actually think that an accessibility lead is necessary. Not so much because it becomes one person’s responsibility, but because it means there’s one person in charge of the decision process. There are aspects of accessibility that are decidedly subjective; having a lead helps to reach decisions more quickly.
Also, while the long-term depends on having a broader understanding of accessibility within the development community, short-term will benefit tremendously from having a go-to person to communicate with.
Posting those slides and sharing them for contribution is a good idea; I actually have a few different WordPress A11y slide sets, dependent on type of audience, and I could share them separately.
-
Aaron Jorbin
The person in charge of the decision process is the release lead. If they aren’t an expert should they defer to someone else who is? Yes. Much like they generally do now.
The problem I see with having an accessibility lead is that creates a situation where the entire team no longer feels responsible for accessibility. Every person that contributes to WordPress should own the accessibility of it.
-
_Redd
Hi Aaron, speaking for myself only, I agree with you that each contributor should “own” the accessibility of my websites, but I feel just as strongly that there are many like me, who don’t have the expertise to do much of the significant work that needs to be done. It is precisely because there are “lead” members in the current group, who give of themselves not only with coding expertise, but with feedback, that I feel encouraged to work at learning the code that makes WordPress accessible. It would be too overwhelming for me otherwise.
For me, an accessibility lead would provide the “backup” needed by beginner-level developers such as myself to enable contributions to the larger (and great) picture that is WordPress–and would directly facilitate growing the group with active members.
-
Joe Dolson
Alternatively, not having a lead means that no one person feels specifically responsible for finding an answer to a question; a lead would simply mean a point person.
I feel that for a release, there should be a single point of contact, so that there’s a clear chain of communication during that release cycle.
-
-
-
esmi
I actually think that an accessibility lead is necessary.
I agree with Joe but from a different perspective. I think each project/development needs one person who looks at all phases from an accessibility perspective during development. Otherwise, it’s all too easy for potential issues to get lost in the excitement of coding a new feature. I agree 100% that accessibility is everyone’s responsibility but, from a management pov, I think having one person keeping their eye on this particular ball would be tremendously beneficial.
-
After Gadget
I really like what was said in the original post, and I’ve also learned a lot from the comments. For example, I did knows some themes were tagged as being more accessible than others. If there were a way to search for themes by accessibility I would have done that in the past and will probably do that in the future.
One question I have, and I’m not sure if this is the appropriate place for it, and where it says about getting more people involved in that make WordPress accessible group. I tend not to be very involved because I’m not a developer. I don’t know about writing code, etc. I’m just a user so I’m often unsure what I can really contribute. I do have an idea of something that would make WordPress more usable for me as a blogger who uses Dragon, but I’m not sure where I should post that idea.
Anyway, I’m really grateful that this group exists and that so much skill and care goes into making WordPress accessible. It really makes a huge difference. Using Blogger is a nightmare in comparison to WordPress in terms of access, both as a blogger with disabilities and as somebody who wants my blogs to be accessible to others with disabilities.
One of the things I like best about what was suggested above is to have more obvious access tags and info/links on every WordPress site because it really feels welcoming and inclusive as the user was not as tech savvy as most of you are (all of you are?) And I think it encourages other people to think about access when it’s just included everywhere as a normal thing that you might want to be searching for.
-
Graham Armfield
Hi @AfterGadget. Just wanted to underline what esmi and _Redd wrote. This group is for anyone who would like to see the accessibility of WordPress improve. And if you have any ideas for improvement we’d love to hear them. I’m especially interested to hear about your experiences with Dragon and WordPress – I think it’s an area that hasn’t received enough attention yet.
-
-
esmi
I don’t know about writing code, etc. I’m just a user
That doesn’t matter. We’d love you to join. The whole point point of this group is that it isn’t just for coders. It’s for users as well. That way, if we pool our resources, we have the skills & experience to recognise potential problems, develop solutions and get them into WordPress core. As an experienced Dragon user, your input would be invaluable.
-
After Gadget
I forgot to click “follow” so I could see the responses to my posts until now.
I use Dragon for everything,including mousing. One of the things that is hardest to do when blogging with Dragon is formatting, such as block quotes, links, centering, inserting images, etc. One of the great things about WordPress for this is that there are keyboard shortcuts for most of those commands, so that I don’t have to click on icon to do them.
However, to find out what they are I have to hover my mouse over the icon to learn that in the future I use alt shift A for making something into a link. There are two problems with this. One is that hovering a mouse over something is one of the hardest things to do with Dragon, and the other is that part of my disability is severe memory impairment so it’s hard for me to remember which things the keyboard command uses A or U or S, etc.
So it would be really helpful to have those commands written out somewhere — either on the icons themselves or on some menu that could be visible in the same area as the text box, or ideally both.
Because what I am doing now is needing to use my touchpad to hover over the thing first find out what the keyboard shortcut is— which is really hard on my wrists — and then write it down on a piece of paper that I can tape to my monitor (writing by hand is also problematic for me). And it will be difficult to get all of those formatting commands onto one small legible piece of paper.
Maybe these are already written out somewhere and I just need to find them. I know blind users who use screen readers don’t use a mouse to click on icons necessarily, but I am guessing that the text reader reads the alt tag that tells the keyboard shortcut?
I also am not sure if there is a keyboard shortcut for inserting media. Or for the various steps of inserting media. My memory is that including pictures has been harder for me since I’ve lost most use of my hands, but I can’t remember the specifics. Maybe some of you know what I’m talking about.
I hope this is helpful and that this is the right place to post this.
-
-
_Redd
@After Gadget Your input is more valuable than you can even believe.
I am NOT a programmer by any stretch of the imagination, but there are many simple things I can do to increase website accessibility. When I try to improve websites accessibility, I am stuck with the horrible option of either writing it on sheer faith that what I am doing is right, or clumsily and inexpertly trying to use assistive technology to test it. I’m not qualified to use that technology, because I am fully sighted and have full use of my hands. I really need the expertise of those who are real and true experts in the use of assistive technology for real and true feedback as to whether the code “works”. We need you, and we need your expertese.
-
David A. Kennedy
@Graham: Huge thanks for putting this together! There’s a ton of great stuff here.
@After Gadget: Your feedback and involvement is essential! We developers need you to help ensure we do it right, and continue to get better!
Regarding the team lead idea: I think a team lead, especially for each release, is vital. I agree with Aaron (and all of you) that accessibility is everyone’s responsibility, but I think a team lead would help keep communication tight. Yes, accessibility challenges center on code more often than not, but it’s also a communication issue many times. An accessibility challenge has to be explained effectively along with potential solutions and the benefits and drawbacks of each. I see the team lead not so much as being responsible for accessibility, but as the bridge between us and the developers and designers. So much of getting to good accessibility solutions is about trust between the accessibility advocates and the rest of the team. Perhaps rotating this slot would help too? A team approach might strike we balance we need.
Regarding the accessibility statement: I would love to see this. In addition to the normal these are our standards, this is our process and here’s what to do if you have a problem, I would like to also see some “heart” put into it. That’s difficult to explain here, but I see a big opportunity to for the statement to serve as an entry point for people who know nothing about accessibility to learn something. I think it has to have some passion to it, tracing back to how the web’s initial vision was something that everyone could use easily. WordPress has a chance to reach a lot of people in this way because it’s so widely used!
Regarding the coding and style guidelines/providing resources: I think creating documentation and resources that talks about how certain areas impact accessibility would be great. For example, if we’re developing theme resources, we might talk about how removing the underline on links effects things, etc. Again, I have some resources that might help, and I plan to do a blog series about the creation of Accessible Zen where I highlight some of this stuff. Happy to use that as a testing ground for some of this.
Regarding education: this is the key. I think we have to really reach the designers and content creators. They are the front lines of accessibility. Yes, the code is vital, but if I’ve been handed a design with little or no thought given to accessibility, we’re in trouble. Similarly, if I have a site that has content in it that has challenge after challenge, we have a long road ahead of us.
Those are my basic thoughts. Sorry for the long comment.
Also, I would be happy to and super excited to help with any of this.
-
-
_Redd
@David A. Kennedy AWESOME comments….I think we speak for all of us when I say that WE are happy and super excited that you’re here!
Please join us at our IRC meetings on Wednesdays, if you can, as well as continue to offer any more insights you may have on this blog!-
David A. Kennedy
Thanks, _Redd! I keep meaning to attend the IRC meetings, but always forget. I’ll have to set a reminder.
I definitely plan to continue to help out wherever I can.
-
-
_Redd
What’s the possibility of setting aside a special web page–or some other common online location–so that developers who need their code tested can put up the test sites in a central location, and those with the expertise to test the code can sign up for real-world testing?
Something similar to the Khan academy’s page for volunteers, in which lessons that need to be close-captioned or translated are available for volunteers to do so?
It would allow people who do not code a way to contribute–testing WordPress accessibility and giving the feedback that is so badly needed.
-
esmi
Would this be in respect of themes, plugins or core?
-
-
_Redd
I’m embarrassed to say I wasn’t thinking deeply enough to recommend it for specifically themes, plugins, or core.
That said, as someone working on a free, accessible theme, I (selfishly) think that a place to test accessibility for themes would probably be a great place to start. Much of our discussion right now is centered on creating accessible themes, so doing so would help us gain some traction in that regard.
I think core has the trac system anyhow. That’s intimidating to a lot of people. Having a more benign interface for themes would give non-coders a place to contribute. Lessons learned from the “crowd-sourced” testing could benefit everyone. We wouldn’t have to keep re-inventing the wheel every time an accessibility problem is solved.
And, if a solution works, then perhaps one of the more expert people in the group could take the solution to trac, for consideration of implementation into core.
-
esmi
As themes and plugins are not “core”, they may not be suited for a Trac-like system anyway. From a purely personal perspective, I think it ultimately has to be down to the developers of these “3rd party add-ons” to take responsibility for a11y levels & issues in their own work. There’s only so much that WPORG can offer in the way of resources.
Speaking from a theme developer perspective (as that’s the area that I have the most experience in and where the most centrally coordinated a11y outreach may be coming from), theme developers need to use their standard tools along with the Theme Unit Test data to check a11y levels. Longer term they’ll have the option of submitting their theme for an a11y audit as part of a WPORG theme submission – which should (hopefully) give them some valuable feedback. There’s also the theme reviewers mailing list for additional support – although if a11y-specific questions create too much traffic, there might be room later on to establish a better support resource,. Ideally that would be here.
Does that help at all?
-
_Redd
That does help–and again, thank you.
Joe Dolson
Potentially useful accessibility plug-in I learned about today at WordCamp Chicago: http://wordpress.org/plugins/media-ally/
-
_Redd
This looks awesome, thanks for passing it on!
-
Rian Rietveld
Tried it, it seems to break the upload.php and the with the setting nothing shows. But it’s a good idea.
-
Joe Dolson
I haven’t tried it yet, but I do gather it’s pretty well in alpha right now.
esmi
Next IRC Meetup
Just a quick reminder that the next IRC meetup will be on Wednesday, 26 June at 19:00 UTC in #wordpress-iu.
Everyone welcome!
If you have never attended an WordPress IRC meetup before, you can find all of the details you will need to join in the Codex’s IRC page.
One topic for discussion is likely to be the development of a proposed accessibility statement for WordPress. To whet your appetite and give you an idea of what we could aim for longer term, have a look at Drupal’s accessibility statement.
esmi
Should We Be Dropping the Role Attribute in Twenty Thirteen Yet?
Your feedback is requested on Trac Ticket 24629.
Cited example: Should the Twenty Thirteen drop the use of the role attribute on the HTML5 nav element on the grounds that the element, by definition, has the role of navigation? Or should role="navigation" be retained in order to support technologies that are not yet HTML5 aware?
My own opinion that the role attribute should be retained for the time being in order to support the widest range of technologies. Dropping it would offer only a marginal benefit in reducing page bloat. Please do weigh in with your opinions on the ticket.
-
tady
Deffo not. The role attribute is still as important now as it was pre-HTML5. A cited counter example: The main element (<main>) has only just been introduced to the HTML5 spec and is recommended it take the format:
<main role=”main”>
Personally feel that it doesn’t make any more or less work to include it. I wouldn’t be in such a rush to remove attributes such as this any time soon. The spec has a long way to go and will change again before it is fully RC, so I reckon removing helpful attributes like roles have the possibility of shooting us in the foot at some point in the future.
-
_Redd
Don’t drop it. We’re finding that HTML5 attributes are starting to gain support, and we’re including it in our sites.
-
ceo
While I don’t think we should be bound to supporting users with outdated software, which isn’t to say state-of-the-art is fully supporting HTML5 anyway, I think the pros of keeping it far outweigh the cons of not.
-
gogreener
Agreed. Is it possible to set a reminder to review it again at a later date?
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
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.
-
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!
I’m wondering if we missed any? I believe some functions, like
and
have title tags built in as well. I’m not as familiar with core so looking through the diff makes it hard to tell. Commenting here to get opinions and not junk up the ticket.