Accessibility Coding Standards now in draft and seeking comments.

Welcome!

The WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:

Found a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.? Create a ticket in the bug tracker.
Want to contribute? Get started quickly with tickets marked as good first bugs for new contributors or join a bug scrub. There’s more on the reports page, like patches needing testing, and on feature projects page.
Other questions? Here is a detailed handbook for contributors, complete with tutorials.

The WordPress AccessibilityAccessibility 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 has created draft Accessibility Coding Standards for the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. handbook. These standards will remain in draft format for at least the next two weeks while everyone has an opportunity to review and comment. If there are significant changes made based on the comments, additional posts here will be made announcing them and seeking further comments.

Please review the draft standards and leave your comments on this post.

hearvox 9:43 pm on January 24, 2016

Great job. “sub sections” is usually is one word:, “subsections”; see 2nd sentence of:
https://make.wordpress.org/core/handbook/best-practices/coding-standards/accessibility-coding-standards/#heading-structure
- Joe Dolson 9:49 pm on January 24, 2016
  
  Fixed – thanks.
jteague 3:30 pm on January 25, 2016

No concerns or errors noted. Thanks to all involved. Anything WordPress can do to make accessibilityAccessibility 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) a priority is important and appreciated.
Andrew Woods 5:48 pm on January 25, 2016

Under the Semantics for Controls section https://make.wordpress.org/core/handbook/best-practices/coding-standards/accessibility-coding-standards/#semantics-for-controls It tells the user to follow the link to TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. to read the logic of how to decide to update the controls. Instead, I’d suggest that logic should be written directly into the a11yAccessibility 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) coding standards.
- Joe Dolson 6:44 pm on January 25, 2016
  
  Agreed; that’ll get moved over soon. Thanks!
- Joe Dolson 12:51 am on February 7, 2016
  
  This is done – thanks!
Carrie Dils 6:26 pm on January 25, 2016

This looks really great! Just a couple suggestions:

Dynamic Content #

Typo: “, like a successful saving for example” should be “, such as successfully saving”

Images and Icons #

Perhaps worth noting that alt tags for ornamental images should be not null (i.e. no to `alt=””` and yes to `alt=” “`
- Joe Dolson 11:29 pm on January 29, 2016
  
  Thanks, Carrie – typo fixed!
  
  I’m not sure I follow your other suggestion – in general, ornamental images *should* have a null alt attribute; I’m uncertain why you would suggest a single space instead? I’m not aware of any benefit to that.
  - Mark Root-Wiley 8:58 pm on February 1, 2016
    
    I know there’s historically been some confusion over whether a space or no space means “there is no alt text provided because the image is ornamental”. (See: http://webaim.org/discussion/mail_thread?thread=2346) I can’t find reference to this, but I think some screen reader implementations at least used to treat those two things differently and possibly not according to spec (which I think you correctly note is null, Joe).
    - Joe Dolson 11:56 pm on February 6, 2016
      
      That’s quite an old thread (2005), and I’m fairly confident that using a space to represent an ornamental image is something that hasn’t been necessary in any environment for quite some time. Even that thread largely identifies a space in an alt attribute as the less desirable choice, however. Thanks for pulling up that reference.
Mark Root-Wiley 10:55 pm on January 25, 2016

> “For icon fonts, the font icon itself should be aria-hidden, with screen-reader-text in a neighbor element.”

I’d recommend including the “neighbor element” in the code snippet so people can see `aria-hidden` in action.
- Joe Dolson 11:31 pm on January 29, 2016
  
  Thanks Mark – I’ve added that to the snippet. Kind of thought I already had, but evidence suggests otherwise!

Comments are closed.

Welcome!

Communication

Share this:

Site resources