This post is a follow-up to the workflow keyword proposed on April 29th, 2021. Originally posted as a comment on the original post by @ryokuhi
The accessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team reviewed the proposal today during the weekly meeting.
As we would like to bring this proposal forward, we investigated some possible keywords and would like some feedback on them.
needs-implementation could be a nice addition to
needs-design usually involves only the creation of a layout,
needs-implementation would convey also the need of an actual implementation to test for accessibility. The downside is that such a keyword would be very similar and difficult to distinguish from
has-accessibility-review (along the lines of
has-privacy-review) could be added after a first triage to exclude tickets from scrubbing until extra feedback is needed. The downside is that often accessibility review is a multi-stage process that needs to happen after each UX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. change, not just once for a ticket: the wording
has-accessibility-review might induce to think that everything is done once the ticket is reviewed.
needs-accessibility-review are keywords that could be added when an action from the accessibility team is required. The downside is that similar keywords don’t really add any extra information if the ticket also has the accessibility focus.
changes-requested underlines the fact that the owner of the ticket needs to do an action before the accessibility team (or any other team) can offer feedback on the ticket.
Apart from adding a new workflow keyword, the team also took in consideration two other options.
- Differentiating between primary and secondary focuses on Trac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. might allow teams to distinguish more easily between tickets they are responsible for and tickets where only feedback is needed. Of course, this would require a change to Trac, which is probably complex and could be done only in the long run.
- If the reporter or the owner of the ticket doesn’t take any action after a reasonable amount of time, the team will change the milestone of the ticket even if it’s not under their direct responsibility. The team consider this as an extreme option to invite who is monitoring the ticket to take action.
The team would like to have another round of feedback on the (updated) proposal and will review it again in one or two weeks.
This is the third post documenting a recent visit to Digital Accessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Centre in Neath, South Wales organised by fellow team member Siobhan Bamber. The first post can be found here, and the second post here.
Three of the staff from DAC gave us feedback on using the WordPress admin screens. Each of the three have a particular impairment, and the visit was a valuable opportunity to learn about ways we could improve WordPress for everyone.
In this post we take feedback from Carly who is totally blind. She showed us how she used a screen reader and gave us some great feedback on using the WordPress admin screens with a screen reader.
I’ve added two patches to trac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket #25459 which solve the meaningful links issue. They use a new function which employs the aria-hidden attribute to allow meaningful text for screen readers to sit alongside shorter text for sighted users, and allows both strings to be translated with correct grammar/spelling in all languages.
They work for me, but it would be great if someone else could test them on their own environment with a screen reader to double check. Maybe we could get this into 3.8.
The patches for Trac ticket 24766 are slated for addition to WordPress 3.7. This is great news for assistive technology Assistive technology is an umbrella term that includes assistive, adaptive, and rehabilitative devices for people with disabilities and also includes the process used in selecting, locating, and using them. Assistive technology promotes greater independence by enabling people to perform tasks that they were formerly unable to accomplish, or had great difficulty accomplishing, by providing enhancements to, or changing methods of interacting with, the technology needed to accomplish such tasks.
https://en.wikipedia.org/wiki/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 Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) issues.
Currently, the excluded methods, functions and scripts are:
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.
Your feedback is requested on Trac Ticket 24629.
Cited example: Should the Twenty Thirteen drop the use of the
role attribute on the HTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites.5
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.
We had a little mix-up with the meeting time this week, due to the change to Daylight Savings Time in the US, so this meeting report may be a little shorter than usual.
However, the weekly meetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. time remains at 20:00 UTC until the end of the month — when we may review and adjust it. Remember that you can convert UTC time to your local time at Worldtimeserver.com.