Core Development WordPress UI Forum Posts
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.
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.
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
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.
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 of id for table headings and the headers attribute 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”?
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
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:
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?
RUN WITH IT! Enhancements are for plugins!!!
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.
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! 
Following a suggestion from @Ryan McCue about making timestamps in post revisions human readable, I’ve set up a test case that uses both human readable and W3C recommended timestamp formats.
All feedback and comments here, please.
1. Is it possible to differentiate between the original text, what has been deleted and what has been added?
Yes very clear
2. Are any of the timestamps perceivable?
I don’t see time stamps on Firefox 10.0.2 , Chrome Version 24.0.1312.57 m IE9 , at least, not rendered as text on the page. Did you mean that the time stamps should be visible in code? I can view code and see time stamps
The visual presentation is being controlled by Twenty Twelve and it is nice to see that it does a good job of it. But what about those who cannot see the visualisation? In theory, the ins and del tags should be rendered appropriately in screen reading software but I don’t know how (or even if) they render the attached timestamps. If they do, then the format of that timestamp may be critical. The sooner we can let the UI team know what format(s) they can (and can’t) use, the better.
Interesting. Hopefully, we’ll hear from some of our experienced screen reader users soon; in the meantime, I may just dig up the iPad and try to see what Voiceover does with that. …..it may have to wait until this weekend, but I think this is most certainly a worthwhile pursuit!
in using JAWS screen reader with I.E. 8 and Firefox 18.0.2 two paragraphs are read but there is no indication of any revisions or timestamp present.
That’s very interesting Heidi. Can you tell us what version of JAWS you are using? I was under the impression that it should be able to support.
That’s great Esmi, it’s great to see it in context. Really looks like a great addition. Be interesting now to hear the feedback from people using SRs now, like Heidi here.
I am using JAWS version 13.0.1006
regarding Esmi’s remark: In theory, the ins and del tags should be rendered appropriately in screen reading software but I don’t know how (or even if) they render the attached timestamps. If they do, then the format of that timestamp may be critical.
… I would think appropriate rendering would be for them not to read in the actual post but should show up in the code so as to appear on the back end … in the code the time stamps are showing, they are nonsense in the first paragraph but read properly in the second. I hope I am understanding the purpose of this test correctly
I just looked at the test page, and using IE9, and Jaws for Windows 13, the timestamps are not visible, and there is no way to determine that text has been deleted. So to go through the test questions:
Amanda
Thanks Amanda & Heidi. Based on the feedback thus far, it seems that JAWS doesn’t render these tags when used with your current configuration. Can I ask both of you whether you are using JAWS in a verbose mode?
I am using JAWS in beginner verbosity mode
As per last week, we had a very lively and interesting meeting with the main focus being Custom Menus (again) and the use of hidden skip links. Thanks to all who took part — especially a couple of UI team members. The inter-team discussion is invaluable as it allows us to get a better perspective on the overall core development philosophies as well as the current development cycle goals. I think the more we learn about the development process, the more effective we can become at offering practical, effective, suggestions at the right times.
@accessiblejoe will be looking at developing videod user tests for the CSUN conference based on the list provided by @GrahamArmfield and the alter discussion on IRC:
We hope that any videos obtained will help the core development teams to gain a better understanding of some of the issues faced by disabled users.
@joedolson is still working on an extension of the Theme Check plugin as part of the optional accessibility audit for all themes submitted to wordpress.org. He now has a modified version of the plugin available for testing and is actively looking for feedback.
There was also a lively discussion of “hidden” links — including both skip links and the current log out link (which is effectively hidden in a dropdown) — and balancing link visibility with the need to avoid a cluttered interface.
Finally, a reminder to all readers that, as a group, we are still stretched pretty thin and would welcome new members — both technical developers and non-technical disabled authors.
Catching up on the chat after I left. I really like the idea of the visible Logout. Glad to see this brought up.
And, in my experience, most of the screen reader users I know use Facebook and Twitter either via the mobile sites or apps because of the inaccessibility. I don’t really frequent many other social networks so can’t comment on them.
This is one that caught my eye too. I wondered about the possibility of integrating an icon font? (An example would be: http://fontello.com/ ) Would this be more beneficial? In this case, the under “Font Awesome” there’s a pretty decent icon to logout. Couple this with an anchor title and it could be small/discreet enough to go alongside the “Howdy, username [Gravatar]” easily. I would envisage a (slow) update of all icons across the dashboard to an icon typeface over time, which would result in this being second nature or intuitive.
As many of these font icons are actually unique entities (i.e. it’s not like the logout symbol replaces the letter “L”), maybe this is creating an element of greater confusion? Perhaps an image with a proper alt/title would be more effective?
A small problem with using icons alone is that speech recognition users can sometimes find it difficult to action the link. Those users can usually access image links if they know what the alternate text is, but of course that is not always obvious.
That said, in this case the alternate text would be very likely to be “log out” or “log off”.
Speech recognition users do have other ways of activating links but they can get laborious.
With icons there could also be the issue that they are not obvious enough for some users – maybe with cognitive impairments.
A small problem with using icons alone is that speech recognition users can sometimes find it difficult to action the link.
As an ex-VR user (try coding in Dragon for 6 months — it’s… interesting), I’m in two minds about this.
Using Dragon as an example, if it is used with IE, all links on a page are given numbers within the browser so you can easily jump to a given link. As I’m a Firefox girl, I looked around for an FF extension that would give me similar functionality. So I’d argue that this really is an edge-case between the web page design and the user’s choices/software configuration. At worst, VR users should be able to TAB to any link in a page — so nothing should be ever completely inaccessible. And if an icon was used, it wouldn’t/shouldn’t be the link itself. The main link’s text would/should still be there to be used.
A friend and I were talking about this……
1. WHAT exactly enables tabbing?
2. Is the tabbing behavior consistent for screen readers, voice-recognition systems, and other AT?
3.is it necessary to also add a:focus if you want the focus to be in sync with tabbing?
I welcome any url links, authoritative sources, or insights on this. I know that between the two of us, we could not answer these questions between ourselves.
1. It’s default browser behaviour. Just like web developers have HTML specs, browser developers have W3C User Agent specs that they need to follow.
2. Pretty much, yes. Different AT might have their own inbuilt helper functionality (which, by & large, is outside of our remit as developers) but, by default, they should all fall back to the default tabbing behaviour.
3. Yes. And if you want to support older version of IE (IE8 or below), you also need to apply the same styling to :active pseudo class.
4. http://accessites.org/site/2007/05/keyboard-friendly-link-focus/
Awesome, thank you esmi from both of us!
I finished the plugin I was talking about the other day and after some initial teething problems it’s now available – through my own site initially but I intend submitting to WP plugin repository when I’ve worked out how I do that.
The plugin places a Log Out link into the admin toolbar. I’ve tested it with Dragon Naturally Speaking and on an iPad and it seems to work OK.
Originally I was attempting to get the Log Out link into the main menu – above the Dashboard link but I couldn’t get that to work properly.
I’d welcome any feedback if people want to try it out – it’s available at: http://www.coolfields.co.uk/2013/02/wordpress-permanently-visible-log-out-link-plugin-version-0-1/
Cool! Have you had a look at Plugin Submission and Promotion?
AWESOME!!! And so timely! Do you forsee any issues with multisite?
@graham
http://red-hound.com/Redd/logintop/login-plugin-test/
So far, so great on WordPress multisite 3.5.1!! Woo! Woo!
Good morning Graham, on one of my test sites (multisite set up) I have both yours and Joe’s plugin activated.
So far, when I am “in” WordPress, the login and logout functions seem to be fine–however, one of the things I do is “View Page” to look at my work, and that opens in another tab.
I get network access message errors when I try to log out through the “normal” logout screen on the new tab. I’m never sure if it’s an actual network problem, but you may want to check the function of the “standard” logout link, on a new tab, with the plugin installed.
The difference between the logout message I get when I log out of a site WITHOUT the plugin activated is ……wp-login.php?loggedout=true
The logout message I get when the plugin activated is….wp-login.php?action=logout&_wpnonce=e965affe42
So it looks like processing a nonce may be the culprit
That said, your plugin and Joes are some of the BEST are REAL progress for WordPress! Thank you thank you thank you!
Hello _Redd, thanks for the notes.
To place the Log Out link in the toolbar I’m using the admin_bar_menu hook to call a function that calls the add_menu() function.
One of the parms I’m passing is the link for the item which is provided by wp_logout_url(). I’ve left the redirect parm empty to allow the default processing. This seemed to me to be the safest way to get the appropriate link as I couldn’t track down the function where the existing logout links are added to the toolbar.
This seems to be correct as per the guidance on the codex – notably: http://codex.wordpress.org/Function_Reference/wp_logout_url but if I’ve made a mistake I’d be grateful of any pointers to the correct way to generate a Log Out link.
I have a test site without my plugin running and the existing Log Out link does include the reference to the nonce.
Thank you so much for the rapid response….a lot for me to learn from, personally, and a lot for me to chew on. And sadly, much is of this is over my head. I’m like a monkey looking at the back of a watch with a lot of this stuff! But! I’ll review the links you’ve provided, revisit this and get back with you for the results…..it might be a couple of days, but will definitely revisit.
Thanks again!
I canot get access directly from http://myvikingdomain.com but can’t get more than ‘you had a typo’–which worked ONLY once. Now I have to go from a ’1 result’ menu (w/o seeing the result) by clicking on the ‘fb’ icon(linked to the domain) to get access. How can anyone get there to read my posts & pages, market my books?
@George Nilsen: Sorry? I don’t follow you…
Thanks to everyone who managed to make the IRC meeting on #wordpress-ui yesterday. We had a very productive discussion and — despite the entertainment provided by way of my terrible iPad typing — took the first steps towards organising the group along more formal lines.
@GrahamArmfield will be looking after Trac. Time permitting, he will be monitoring the existing accessibility-tagged tickets and taking the lead on the submission of new Trac tickets to cover issues such as the problems within the current custom menus admin area. So if you are thinking of raising a new Trac ticket, can you raise the subject here first? That way, we should avoid unnecessary replication.
@joedolson expressed a vested interest in the editorial flow area but, for the time being, will be concentrating on front-end accessibility via the proposed theme accessibility audit and an extension to the current theme submission checks.
@AccessibleJoe will take the lead on user testing videos so that we can build up a library of video resources to support core developers.
@esmi will continue to take lead on documentation (liaising with @Siobhan and @DrewAPicture) as well as working with @lessbloat and other members of the UI team to try to develop in-house user accessibility testing.
We are, however, still stretched pretty thin. So if you would like to get involved, we would love to hear from you. Those of you with the skills to create patches will be particularly welcomed by the UI Team who are currently overhauling the Custom Menus and Post Revision areas.
I’m sorry, I was out yesterday! I missed so much! I am so so glad to see this move forward, and I will coordinate to help however possible. I’ll be in touch. Thanks to all for the committment to accessiblity.
esmi, I am reading through the IRC Ui-channel chat entries from yesterday, trying to catch up. I found the following statement: esmi
Does anyone else read the other core P2 blogs regularly?
What are the P2 blogs? Are they the same thing as the IRC logs?
@esmi is referring to the P2s that make up the Make group of sites. We call them P2s because they use the P2 theme.
Thank you!
Hi. I was hoping to stop by yesterday just to listen, but kept forgetting to go to time zone converter to figure out what time it was. I don’t think I have much to offer right now as I’m still learning a lot of the terms you’re using. But I’m grateful this group exists.
>>So if you are thinking of raising a new Trac ticket, can you raise the subject here first?>>
Since this seems to be a general request, would you mind explaining what it means, so I can try to comply?
Trac is where bugs are reported and other changes to WordPress are, well, tracked. It can be intimidating for those unfamiliar with it, so if you are not comfortable submitting a bug we ask that you report things here. Also, we want to avoid duplicate tickets. (An example of an ongoing Trac right now, is the Custom Menu enhancements.)
For reference: http://codex.wordpress.org/Reporting_Bugs
We’d love to have your input at the meetings but if you can’t attend, there should always be the posted summaries the day after. Plus I’ll try to always include a direct link to the IRC logs for that day & channel so you can read the full discussion at your leisure.
Thank you esmi and ceo!
“@AccessibleJoe will take the lead on user testing videos so that we can build up a library of video resources to support core developers.”
Regarding videos, will they be accessible via captions? There are developers who are deaf. Thanks!
Yes. We’ve already discussed this at some length both at the meeting yesterday and via email today. We will ensure that captioned versions of videos are widely available.
Over the last few months WP dev lessbloat has done a series of videos where he has invited in ‘real-life’ users to try out various features of the WordPress backend – and has videoed the experience.
I’ve watched many of these videos and read the transcripts of the interactions and they are a really great insight into usability, and assumptions that developers make about how much users understand about what’s expected of them. The most recent one is at: http://make.wordpress.org/ui/2013/01/09/two-more-menus-user-tests-focusing-on-this/
I’ve often thought that it would be quite revealing if somehow we could produce a series of videos of blind and motor impaired users trying out key bits of the admin area. These would highlight the accessibility issues perhaps more than words on a page could, and could constitute a powerful benchmark on which to base future improvements.
Does anyone else think this might be useful? And if so, how could we go about making some?
User testing is a powerful tool and can be very revealing.
When the users being tested are local, for this type of usability testing I use Silverback by Clearleft Limited. It captures screen actions and embeds a video of the user in the frame. The user is captured by the built-in camera in the computer. Silverback is for Mac. http://silverbackapp.com
This is not the only scenario. Remote user testing is also available. Here is an article listing some of the companies that do this: http://www.actualinsights.com/2012/free-remote-user-testing/
Finally, asking for free participation in such studies is a sensitive issue in the disability community.
The CSUN conference is coming up soon. I will devise some tests – I will take input from this group about the focus of those tests. I will put out a call for people to meet with me at the conference to do some testing. I will capture the experience with Silverback. I would like to offer something to participants – a Starbucks card for example – is there any budget for this?
Thanks for your reply Joe.
I’ve also seen some very useful accessibility tests of some websites that were done via sharing the screens over Skype and recording the results via Camtasia studio. Perhaps not as sophisticated but valuable nevertheless.
The issue about budget is a good one. I’m not close enough in to the WP organisation to know about that – Esmi may have to comment on that. It would be interesting to find out if lessbloat gets a budget for his vids and gives his paricipants anything.
Your idea about CSUN is a good one. For my money the focus should definitely be on things that are obviously not accessible – like Custom Menu Builder, etc. But it would be good to test the whole process of adding a new post with some media and some links and headings within the page. After all, that’s the key functionality that needs to work for everyone. Itwould also be nice to test things where the situation has improved recently after the tickets that got included within 3.5.
Another issue is how widely these videos are publicised if they ever get made. My natural gut feel is that full public airing is good – for knowledge, and as a spur to improve. But I know that perhaps not everyone might agree with that.
I’ll post the videos on YouTube and promote them to the accessibility and WordPress communities. I can’t do this alone. I will commit to getting people to engage in some focused testing. I cannot afford the time to CC the videos and provide audio description, which the videos will need. We’ll need someone to do that.
I’m willing to help with this Joseph.
Creating captions is not necessarily difficult but can be time consuming. But I’ve done some recent experiments and the facility within YouTube to create a captions file from a transcript actually works really well most times. Now it’s a lot easier to crowdsource the production of a transcript for a video than a caption file directly.
With transcripts, you or I can upload into YouTube to use as the raw material for a caption. It’s then possible to hack the YouTube caption file where the auto-syncing hasn’t worked so well.
So a possible workflow for each video would be:
1. Shoot and edit video, and upload to YouTube.
2. When someone has created a transcript we upload that to YouTube and go with the transcript-fed captions.
3. Where necessary, people identify segments where the captions aren’t synching right and one of us tweaks as required.
By the way, you’ll not be surprised to hear that the auto-captioning facility within YouTube is laughably bad.
Do you need to create a WordPress Accessibility YouTube account? Is that the best idea? What does everyone else think?
I believe we should start a WordPress Accessibility channel on YouTube only if we expect to regularly post to it. Otherwise, if I do a few user testing videos I can just post to my own channel.
Thanks Graham, I’ve captioned lots of videos and know how time consuming it can be.
As far as I am aware there are no budgets available to anyone via wordpress.org. Where people do have access to user testing & video facilities, I would imagine that they are being provided as a form of sponsorship via their employers.
Will WordPress have a presence at the CSUN conference? I will see if people will attend a WP Accessibility group Tweetup.
I’ll be attending CSUN, and would certainly attend a WP accessibility Tweetup.
Good man! I’ll start promoting it.
There will be a general Tweetup, look for info at http://www.csuntweetup.com/
The CSUN Tweetup page has not yet been refreshed for #csun13.
I’ll run the WP Accessibility Tweetup through my Meetup group:
http://www.meetup.com/Los-Angeles-Accessibility-and-Inclusive-Design-Group/
First I have to set a day, time, and location.
Unfortunately I won’t be able to come to CSUN this year – shame as I’d like to me you all. Hopefully next year.
I’ll be following CSUN tweets – though not necessarily live given the California/UK time difference…
Esmi, do you know lessbloat? Can you ask him how he goes about it, and whether he’d be up for doing any with user with disabilities? I’ve suggested it at least once in my comments on his posts but not had any response from him.
I think this would be an excellent idea and is very much in line with my hopes of building up a pan-disability panel of users within this group.
Joseph, that website you provided on actualinsights.com is great. I see that they have an app for iPads and iPhones–which to me, is huge. I had been looking a LONG time for something like this…..THANK YOU.
http://www.actualinsights.com/2012/ux-recorder-screen-recording-app-for-ipad-iphone/
Combining Reflector and Silverback for iOS Usability Testing http://bit.ly/V6zS3m
It is also important that videos are captioned and transcribed for those who cannot hear. None of WordPress.tv videos are captioned at all – to say nothing about many other online videos on other websites.
I don’t believe WordPress.tv has the ability as yet to transcribe videos. Though, even a separate text document/page/whatever would be beneficial in lieu of an actual transcription until something changes. Even something as simple as a detailed description of the video could be helpful.
WCAG and Section 508 both require that video be captioned. Transcripts may be posted as a stop-gap measure until the video is captioned. Detailed description does not meet the criteria for success. Captioning services can deliver finished captioning quickly and economically when organizations don’t have the labor to do the job.
The larger question for us all is: do we want to include all users, or do we find it acceptable that some are excluded?
Good question Joe. My view is that we should aim to include all users, but understanding that that is not always possible – certainly initially.
You’ll see my comments elsewhere about the provision of captions and how that could work. Cyndy’s point about wordpress.tv and captions is important. Captions isn’t the only accessibility issue with wordpress.tv.
I think signed versions might be something that might be hard to deliver on a limited budget, and I’m not sure about adding audio descriptions.
wordpress.tv has many problems with accessibility – eg lack of captions, and poor keyboard accessibility. It really needs to change.
If WordPress wants to host the videos themselves then they need to embed them with a player that is keyboard accessible and supports captions.
I’ve done a bit of work using the player that is available from Nomensa (http://www.nomensa.com/about/news-items/nomensas-accessible-media-player-20-now-free-download) which is pretty good for accessibility (keyboard control, captions) but with some limitations.
I’ve created a crude WP plugin that incorporates it which I’ve used on a couple of sites. It’s not on general release as it’s nowhere near finished. But it works with videos hosted on YouTube.
The biggest limitation of the Nomensa player at the moment is that for YouTube vids the player always uses flash which means that it’s not natively available on iPads and iPhones. However, if you’re hosting the vids yourself it can allegedly pull in the JWPlayer which allows delivery using the HTML5 video object on browsers that support it – should include iOS devices.
Maybe consideration of the accessibility of wordpress.tv needs another thread – it’s a big subject.
Maybe consideration of the accessibility of wordpress.tv needs another thread
Agreed – as that might be edging to wards the edge of our remit. One area that is definitely within our remit is to review all videos used in support documentation – such as those being incorporated into the new User Handbook.
do you know lessbloat?
Not spoken to him myself but I will try contacting him for details.
Update: Had a quick chat with lessbloat. He’s using usertesting.com and, as he works for Automattic, they are kindly picking up the tab for the tests. Had a quick look at the pricing structure for usertesting.com and it would work out pretty expensive if you wanted to carry out more than a couple of testing sessions.
We now have a form that allows assistive technology users to send us their feedback via email. My guess is that not everyone is comfortable contributing to a public discussion here. Longer term, I’m also hoping that we can build up a pan-disability panel of users who would be willing to help with testing.
I’ll spread the link around, esmi! And, I’m certainly more than happy to help out in any way that I can.
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.
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.
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.
Accessibilty Specialist. Federal 508 SME
Hi Barry. Can you tell us a little more about your professional background? Google is not being helpful.
Hello, I am a technology blogger. I would like to be a part of the new accessibility group.
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.
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…
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.
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.
There are serveral reasons for having the admin bar at the bottom, HTML-wise (listed in no specific order). One is speed. Putting the HTML (and the JS that powers it) at the top results in “blocking,” which makes pages slower to load. And if the HTML is up top, but the JS is at the bottom, then the bar doesn’t work for a variable amount of time. Second, it is better for search engines. Content should be nearer to the top, not buried under menu bars. Thirdly, it is better for accessibility, as you noted, in the respect that people don’t need to continuously get past all that HTML to get to the content.
Your hidden skip link idea is an interesting one! Thanks for the feedback.
No problems, glad to help. Fair points made there Mark, and I do agree with you completely about the load times, etc. I kind of thought about it while writing the suggestion, and it made more sense to me to have it at the bottom while I wrote my thoughts, which is why I suggested the skip link. I think it’s the only way to ensure accessing the toolbar (accessibly) from the top of the page.
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
Hi folks.
I’m simply a user of WordPress, and hope to test out the accessibility of the upcoming stuff you mentioned on the comments.
I’m a totally blind user, and primarily use three different Windows-based screenreader programs.
NVDA (Non Visual Desktop Access) JAWS for Windows from Freedom Scientific, also called (jfw) and also have in the last year began working with SystemAccess, from Serotek.com.
I was working with GWMicro.com’s Window-Eyes screenreader, but I’m growing tired of waiting around for them to rewrite the browse mode, stick aria support into there product, and such.
Until they do this, I will not be actively testing it with things.
Primary browsers I am using:
Internet Explorer Nine and Firefox Four.
I mention this information because is primarily what I have at my disposal for accesibility testing.
I’d like to know more information on how I can test (since I am blind) I won’t be able to ehlp you folks with visual based questions like color, and other little issues like that.
They’ll need to be about thigns like: if I can’t navigate by heading, if form feeleds are not properly labled, and so on.
One thing (though I could be wrong) was when I began using WordPress a few months ago, sometime last year, was that I found switching to a new theme to be toally inaccessible, no matter what screen-reader I used.
Has this ever been looked into?
I’m also curious if a time limit exists as far as gaining access to WordPres through the beta-tester plugin.
I ask because I don’t have WordPress presently installed.
A friend of mine is giving me access to a web hosting platform where I ‘ll be able to set this up.
As soon as I do, I’ll happily grab the beta-testing plugin you meitno, so will be saving this page to my favorites (assuming this post doesn’t go down soon) so I can remember exactly where to grab the plugin.
Searching the plugins is nice, but having the direct location is far better!
Take care everyone!
If using my primary email, I won’t accept spam. I get enoguh spam messages from epople I don’t know as it is. Just a point.
You’ll find my email in the comment submission form!
Well labled by the way, although I have one suggestion in future development right now on the comment form.
The last labled form you have is the “website:” edit box.
The comment box only says “edit” perhaps lableing it “comment:” would be better, so that all screenreaders would say “comment”?
Just a thought!
Having an unlabled edit box in any case is a bad idea (especially because it is probably to the majority fo new users who are blind and such using wp they might not know that you wish a comment to be present in that feeled. So they might think: “What”?
Anyhow that’s that!
One other public feedback for everyone here:
The replybutton however is labled so only the comment editbox is not.
Can anyone confirm if this is always the case ( regardless of theme)? If so, then this small but seirous adjustment needs to be made by the primary coders of WordPress (of wich I am not.)
I can only test. I cannot implement my own suggestion about a small suggestion like insuring that in future software releases beta or otherwise that the comment box is labled like this: “Comment:”
Without the quitees.
Our screen-reader will identify the box as an edit box if you folks code it properly, so just typing:
comment:
as the lable is good enoguh in future releases.
Please submit this feedback to Mat and th other primary developers, I’d appreciate that as a first-step of the future of WordPress accessibility!
Thanks a lot!
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
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
I have found one issue. you got my email and I am on twitter @azizur
OK – first test I ran and it failed miserably! Please, please, don’t assume that every keyboard navigator is using a screen reader. The vast majority of them won’t be. The skip link isn’t available visually (and that’s a pretty basic fix these days) and there is absolutely no link highlighting. End result: you’re completely lost within about 3 keypresses (?sp).
And while you’re looking at highlighting for sighted keyboard navigators, what about some highlighting on form imputs that have focus? Again, very simple to implement but with a major impact on overall accessibility.
Contrasts – why black text on a white background again? That’s going to cause major problems for most dyslexic users and a significant number of visually-impaired users (ie those using screen magnifiers). A contrast of 21:1 really isn’t necessary for a default stylesheet. Dropping #000 down to #404040 (or even #505050) would still comply with WCAG 2 AAA requirements in terms of contrasts. Bizarrely, all links fail AA contrasts miserably (only 3.6:1), so I’m struggling to find the logic here.
The :visited link pseudo styling is also missing. I’d argue that could be an access issue for those with reading, language or learning difficulties. As could the removal of the underline on links. Mouse users don’t really need the underline onhover. They get feedback from their cursor. Some color blind users, however, may have trouble locating non-underlined links. Try greyscaling a page and you’ll see what I mean.
Not sure I agree with the plethora of H1 tags in terms of providing a logical and hierarchical header structure in order to convey a mental model of the page, either. Navigating the main posts page via a Headings List is going to be real fun!
Overall and after an initial scan, I’d describe my reaction as “disappointed”.
This is super helpful, thanks! Bear in mind that the theme team are designers by trade, not accessibility experts, so let’s not assume any decisions were made to impede accessibility — they were made to make a great-looking theme. If we all assume the best, not the worst, intentions and keep our tones in line with that, it makes critical feedback much easier to take gracefully.
Sorry – I hope that implication didn’t come across in that way. If it did, it’s probably born out of frustration as these are some of the issues I’ve been trying to battle against over many years. I think the situation regarding accessibility might well be summed up by a comment I published some years ago:
My own personal feeling is that, because visually impaired users have been early adopters of assistive technology and have, very successfully, highlighted the problems that they face, the balance within accessible web design has become somewhat skewed in their direction.
http://blackwidows.co.uk/blog/2006/10/16/designing-for-dyslexics/
@esmi: Do you have a good link to information about why black on white text is problematic? If we can point the theme designers to information that can help rather than just telling them it’s bad, that would be helpful.
Body text appears to be #333, not #000; which text are you considering problematic? Could you take a picture of the issues as seen with a screen magnifier?
It’s been found that very stark contrast between text and background can be of hinderance to people who suffer from extreme dyslexia. This is often aided (especially for kids in school) by using glasses with tinted lenses to change the background colour in relation to the foreground i.e. printed text on paper. Reducing the foreground colour “softens” the text against the background and can aid making it slightly easier to read.
I would hasten to add that, like fingerprints, not all types of dyslexia are the same, in the way that not all colourblindness is the same. There will be no “one fix, fix all” solution for this but esmi’s points are quite valid.
I would point out to esmi though, that the CSS style sheet does have “:focus {outline: 0; }” which is accompanied with the comment “remenber to define focus styles!” This does push the responsibility back on the developers of the site to ensure that a focus style is provided for both keyboard and clicked indications.
As HTML5 has changed the use of headers to apply within specific articles or sections, there is now no longer a requirement for single H1′s on the page, but I agree with esmi, there should still be some rationale behind their application. I fear that removing the strictness of their hierarchy will lead to worsening accessibility support, but this is a conversation to be had with the HTML5 gods! WebAIM recently completed a survey with users who require screen readers and found (surprisingly) that just over 50% (of ~1250) expected to find two H1′s on the page. I think this is a conditioning thing; the developers have put two H1′s on pages for so long, that the users who require screen readers have come to expect to find them. That’s not to say it’s correct, but I think this is where the reason arises.
Hope this helps…
Yes, having a dyslexic high-schooler, I’ve been given the “have her read through yellow cellophane or tinted glasses” spiel. Was hoping for a link to an authoritative resource so the theme designers coud learn from the source (promote proactive rather than reactive responses, etc).
I don’t have any authoritive link on this at the moment, but I will see if I can find you something. I didn’t think the suggestions were as primitive as to cellophane, I thought opthalmists were aware of this and had proper solutions. As far as I am aware, it is very much hit and miss as to which colours work for the individual, though I believe variations of yellow or pink are best. I will do my research and get back to you.
Here you go, this looks pretty helpful:
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/
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
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
aside normal links there is no keyboard focus – a keyboard user does not really know where he is on the website
there is one on forms – a transition making labels and required asterisk vanish. this is a really nice thing, but one has to remember what the field is for and if it is required.
drop down menu (main navigation) is not keyboard accessible – this is a heavy problem, because WordPress is not that good in orientation issues. And how should a keyboard user get to a sub level in main navigation apart from accidentally?
show room slider is keyboard accessible, but you get no focus to know that this is a slider
Also link hover and active state could be improved – it’s only css so far
3. heading structure
First I was really “shocked” that every headline was H1, but you are of course using html5 elements as aside which can contain a H1.
But JAWS doesn’t recognize this until now and has only to much H1 elements.
Also NVDA doesn’t interpret the html5 hierarchy until now.
There should be a choice if one keep the “old” hierarchy model to support screenreader users better than having a lot H1s elements. I know it’s not that easy to decide …
4. without color: content should work without color information
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 …
required asterisk: also current screenreader support aria-required to mark a field as required, you should have a kind of fallback: the asterisk – but it should be put into the label to be read by a screenreader in form modus – also should there be a kind of info what the asterisk mean …
header image: should have a filled alt attribute – it is big and not in the background and the pictures are very nice – so every one should get them. Unfortunately there is up till now no possibility to add alternative text to the header images …
So – this was a quick review and for a more detailed analyses I have to have more time.
Hope this helps and greetings from cologne germany,
Sylvia Egger
http://accessible.sprungmarker.de
@sprungmarkers
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!
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
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.
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?
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.
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
seablackwithink, and 1 other are discussing. 
_Redd and 
heidi, 
Sveta, 
Bob Easton, 
flick 7:54 pm on May 23, 2013 Permalink |
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 8:20 pm on May 23, 2013 Permalink |
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.