WordPress.org

Ready to get started?Download WordPress

Make WordPress Accessible

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Graham Armfield 10:22 am on October 22, 2013 Permalink
    Tags: ,   

    Welcome to the Make WordPress Accessible Team 

    Hello. You’ve found the blog of the Make WordPress Accessible team – a bunch of volunteers who are striving to improve the accessibility of WordPress.

    Some of us are techies, some of us are not. But we are united by a desire by see WordPress become accessible to as many people as possible. That’s so important now that WordPress powers over 20% of the world’s websites.

    But we need your help.

    We are currently a small team, and we’re interested in including anyone who’d like to help us work towards our goals. The more of us there are, the more powerful and productive our team becomes – so we’d love to have your input and perspectives.

    So if you’re interested in joining us please read Get Involved with the Make WordPress Accessible Team to find out the different ways you can reach out to us and get involved.

    There is now a real momentum building within WordPress to improve accessibility – why not join in?

    Please note: This blog is not the right place to request support for your own site. Please post any support requests onto the wordpress.org support forums.

    Thank you.

     
  • Graham Armfield 11:30 am on November 28, 2013 Permalink | Log in to leave a Comment
    Tags: , ,   

    Analysis of what gets into the alt and title attributes when adding an image into a page/post 

    There was some debate in last night’s IRC chat about trac ticket 26270 raised by @yaelkmiller. Her original point was that when adding images to pages and posts, the Alt text box should have more prominence than the Title box – the alt attribute being an important accessibility feature.

    Personally, I think the idea is a good one, but discussion and comments by @helen also revealed some interesting behaviour when inserting images concerning what text ends up in the title attribute of the image, and what text ends up in the alt attribute.

    I’ve done a series of tests using different use cases and they are presented in the tables below – including my expected results and the actual results.

    Uploading images

    Test No. Use Case Graham’s Expected Result Actual Result in Page
    1 Upload image, add it to page with no change to Title box or Alt text box Title attribute set to image name minus suffix Title attribute absent, alt attribute set to image name minus suffix – ie what the Title box was set to
    2 Upload image, add it to page but change Title box, not Alt text box Title attribute set to amended value Title attribute absent, alt attribute set to amended Title box value
    3 Upload image, add it to page but change Alt text box, not Title box Title attribute set to image name minus suffix, alt attribute set to amended value Title attribute absent, alt attribute set to amended Alt text box value
    4 Upload image, add it to page but change both Alt text box and Title box Both title and alt attributes set to amended values Title attribute absent, alt attribute set to amended Alt text box value

    Using images from media library (previously uploaded) without amendment

    Test No. Use Case Graham’s Expected Result Actual Result in Page
    5 Add image from media library that has Title box set but not Alt text box Title attribute set but not alt Title attribute absent, alt attribute set to whatever Title box was before
    6 Add image from media library that has Alt text box set but not Title box Alt attribute set but not title Alt attribute set but not title
    7 Add image from media library that has both Title box and Alt text box set Both attrubutes set Title attribute absent, alt attribute set to whatever Alt text box was before
    8 Add image from media library that has neither Title box nor Alt text box set Title attribute absent, alt attribute empty Title attribute absent, alt attribute empty

    Using images from media library (previously uploaded) but making amendments

    Test No. Use Case Graham’s Expected Result Actual Result in Page
    9 Add image from media library, that has just Title box set, update Title box Title attribute set but not alt Title attribute absent, alt attribute set to whatever Title box was amended to
    10 Add image from media library, that has just Alt text box set, update Alt text box Alt attribute set but not title Title attribute absent, alt attribute set to whatever Alt text box was amended to
    11 Add image from media library, that has neither Title box set nor Alt text box set, update Title box Title attribute set but not alt Title attribute absent, alt attribute set to whatever Title box was amended to
    12 Add image from media library, that has neither Title box set nor Alt text box set, update Alt text box Alt attribute set, no title attribute Title attribute absent, alt attribute set to whatever Alt text box was amended to
    13 Add image from media library, that has both Title box and Alt text box set, update Alt text box Both attributes set Title attribute absent, alt attribute set to whatever Alt text box was amended to
    14 Add image from media library, that has both Title box and Alt text box set, update Title box Both attributes set Title attribute absent, alt attribute set to whatever Alt text box was originally set to

    Looking at the results

    Using the Add Media Panel to insert an imageThe first revealing thing about these tests is that my own view of how I thought WordPress worked is at odds with the actual results in most cases.

    The second thing that’s become obvious is that it’s actually impossible to set the title attribute for an image whilst using the Add Media panel. The title attribute never appears in any of the results.

    Actually the only way to set a title attribute image within pages and posts is to use the older image edit dialogue box once the image is placed within the page (or to manually update the HTML obviously).

    I think the confusion comes from the labeling of the Title input field in the Add Media Panel. Helen refers to this in her comments on the trac ticket I believe. Maybe to avoid confusion this box should be given another label – ‘Image name’ maybe. I confess that I hadn’t noticed this change in WordPress behaviour – it did used to be possible to directly influence the title attribute of an image when uploading and adding it to a page/post.

    I’m sure that I’m not the only one who didn’t appreciate this situation. There is a plugin called Shutter Reloaded that I’ve seen on a couple of sites, which uses the title attribute from the image to provide a caption beneath the image when the full size is shown. Obviously this plugin is broken if site admins don’t realise the title attributes aren’t being written into the <img> tags – and the plugin author perhaps doesn’t realise either. I can’t comment on other lightbox plugins.

    What do you think? Is this what you expected? Is this the right way to go?

     
  • Joseph Karr O'Connor 5:59 am on November 22, 2013 Permalink | Log in to leave a Comment
    Tags: , codex   

    Review and re-write of Codex Accessibility page 

    The accessibility statement is now added to the Codex Accessibility page. It is time to review the content and edit the page. If you have an outline you’d like to propose for the structure of the page or observations about the way the page is now structured please post here so we can discuss.

     
    • Andy 10:36 pm on November 22, 2013 Permalink | Log in to Reply

      Thanks for starting this thread, Joseph. :) My take on it: The main Accessibility page in the Codex serves two big purposes: Introducing accessibility to current WordPress users, and introducing accessibility implementation to users who are new to WordPress.

      1. Introduce Accessibility & Inclusive Design.

      When someone hits the Accessibility page on the Codex, we can’t assume too much about who they are or what their purpose is. So start off with a brief synopsis of accessibility & inclusive design is, and why it matters.

      I suggested we look at addressing the POUR principles, why they’re important, and how it relates to WordPress. There’s a hefty article on the topic from WebAIM. If we can boil all of that down into a brief set of bullet points, I think we’d be on the right track.

      2. Segment the audience.

      Subheadings for different groups — e.g. users/administrators, designers, and developers — to explain what role they play in making a site accessible.

      3. Summarize guidelines for each group.

      • Users: Speak to content. Alt & title attributes, captioning video, using subheadings properly, creating clear navigation structure, etc.
      • Designers: Speak to visuals. Layout, item scale, whitespace, font size, contrast, etc.
      • Developers: Speak to markup, using semantic code, etc.

      Deeper stuff can be tackled on separate pages related to each audience.

      That’s my more-than-$0.02 perspective as a new member of this group. :) ^am

    • _Redd 1:20 pm on November 25, 2013 Permalink | Log in to Reply

      1. I think breaking down the information on a page by audience is a FANTASTIC idea. I think that by doing that, we will increase our ability to reach others almost exponentially. Accessibility is such an all-encompassing issue, that if we don’t break it down, it’s too overwhelming for almost anyone.

      Breaking the information down into segments will also help us focus our energies. As “audience” needs become apparent, we can target our responses better, too. I can’t speak highly enough about this idea of breaking our page out to address different audience groups.

      2. I recommend adding a “Testers” group to the above three already mentioned (Users, Designers, Developers). Those who test have a separate and specialized knowledge of WordPress that is a combination of the other three. And, we can offer something in return if we have a group of testers…we can offer a bullet for their resumes. It’s a big deal to say that one was part of a R&D team to test new accessibility features on a web platform. Those who rely on assistive technology already have plenty of hurdles finding employment; working with an R&D group has to look good on a resume for anyone. And we need their specialized knowledge.

      3. I would add, or modify, the following statement:

      The main Accessibility page in the Codex serves two big purposes: Introducing accessibility to current WordPress users, and introducing accessibility implementation to users who are new to WordPress.

      The modification I would recommend would be that the purpose of the page not only be to “introduce” accessibility implementation, but to support, foster, and grow it, by serving as “the” go-to resource for all things WordPress accessibility related.

      Andy, I think what you wrote here was absolutely TERRIFIC. I hope we can pursue this as the direction for our next steps as a group.

    • David A. Kennedy 2:31 pm on November 26, 2013 Permalink | Log in to Reply

      I am 100 percent on board with Andy’s suggestions.

      I also think we can spend some time pruning and refreshing the resources list near the bottom of the page.

      How do we want to start working on drafts?

      • Andy 11:51 pm on November 26, 2013 Permalink | Log in to Reply

        Thanks for the feedback! :) For drafts, perhaps a shared Google doc with public viewing rights and limited editing rights? That way anyone can see what’s being discussed, and if they want to participate in the work they can come back here. It would also give us the convenience of inline commenting and discussion. Certainly something we can discuss during tomorrow’s chat, I think.

    • _Redd 1:12 pm on November 27, 2013 Permalink | Log in to Reply

      Talk about timing! Using Google Docs was implemented by the Post Meta Team last night. They started a Google Doc collaborative document for their work . Here’s a link to the recap. It’s a great topic for bringing up at the meeting tonight.

    • Andy 9:42 pm on November 27, 2013 Permalink | Log in to Reply

      I’ve started a draft document based on the rough outline I proposed above. It’s open to editing. Perhaps we can set up a separate time for working on this together, outside of the weekly IRC team meeting?

  • Joseph Karr O'Connor 5:46 am on November 22, 2013 Permalink | Log in to leave a Comment
    Tags: , ,   

    IRC Meeting: November 20, 2013 

    The time of the weekly Wednesday Accessibility Team meeting is now 20:00 UTC.

    A ticket to create the accessible-ready tag for the theme check process has been posted.

    The accessibility statement is added to the Codex Accessibility page.

    We discussed reviewing and re-writing the Codex Accessibility page.

     
  • Joseph Karr O'Connor 9:11 pm on October 23, 2013 Permalink
    Tags: , ,   

    IRC Meeting: October 23, 2013 

    Thanks to @grahamarmfield for the new welcome message on Make WordPress Accessible and for the new page Get Involved with the Make WordPress Accessible Team.

    We have a draft of theme check Accessibility Guidelines and need a tag to attach to themes that make it through the voluntary process to be approved as accessible themes. We decided to do some user research to determine which terms people use when searching. We will use that info to inform our choice of tags.

    In order to help do that research the team decided to start a Facebook page to hopefully reach people we are not reaching now with this blog, our @WPAccessibility account, and our LinkedIn WordPress Accessibility Group. We will also reach out to our local WordPress Meetup groups to help us do the tag research. Finally, we have asked @samuelsidler to find out if there are stats for theme search that we can use to further refine our selection of a tag or tags.

    We will also review content inventory on this blog and pages and give some love to our Accessibility Codex page.

     
  • Joseph Karr O'Connor 5:12 am on October 15, 2013 Permalink
    Tags: , ,   

    IRC Meeting: October 9, 2013 

    We discussed accessibility progress made by @grahamarmfield, @rianrietveld, Bram Duvigneau and others at WordCamp Europe. Rian wrote something about it: http://blog.rrwd.nl/2013/10/09/wordcamp-europe-2013-lessons-learned/

    @joedolson and @sabreuse continue to help with the Twenty Fourteen theme.

    We discussed communications channels: Twitter account @WPAccessibility, Make WordPress Accessible for public discussions of the group, an email list for prep work, the WordPress Accessible LinkedIn group for public discussions for everyone, and IRC discussions for working meetings. Also discussed was the possibility of creating a Facebook page which the group decided against doing.

    @rianrietveld and @atimmer discussed setting up a testing environment and will continue that discussion offline.

     
    • scarlett007 2:42 pm on October 27, 2013 Permalink | Log in to Reply

      hello, would appreciate if you could help me with this, last night I was uploading themes from wordpress
      and I got this message
      home/content/16/9034616/html/wp-content/themes/vantage/extras/settings/settings.php on line 65

      How can I access to remove that theme and get back to normal, why is wordpress sometimes so complicated

      • scarlett007 2:43 pm on October 27, 2013 Permalink | Log in to Reply

        Sorry this was the actual message

        Fatal error: Call to undefined function wp_is_mobile() in /home/content/16/9034616/html/wp-content/themes/vantage/functions.php on line 217

      • Ipstenu (Mika Epstein) 3:07 pm on October 27, 2013 Permalink | Log in to Reply

        Please post this in the WordPress support forums – this is not the proper venue for getting help.

  • Joseph Karr O'Connor 4:39 am on October 8, 2013 Permalink
    Tags: , ,   

    IRC Meeting: October 2, 2013 

    The team discussed active tickets including http://core.trac.wordpress.org/ticket/25054 3.8, sabreuse->(no owner), new, Twenty Fourteen Accessibility fixes.

    A list of accessibility tickets: http://bit.ly/1glL1bH

    A team member has set up an accessibility test server pulling the updates for team use.

     
  • Rian Rietveld 5:57 pm on October 1, 2013 Permalink
    Tags: , MP6   

    Hi, I’m not sure of this has been discussed before, but I saw the vote on the new MP6 theme. http://polldaddy.com/poll/7437854/. Has a colour scheme with sufficient contrast been suggested already? Maybe not for the default theme, but as a choice? In all of this themes the grey in the input fields is very light, did someone do some calculations on this?

     
    • Graham Armfield 6:46 pm on October 1, 2013 Permalink | Log in to Reply

      A very good point Rian.

    • _Redd 6:47 pm on October 1, 2013 Permalink | Log in to Reply

      Hi, Rian, I LOVE the new MP6 theme, but I was really glad to see an eye out for checking color contrast.

      I was unable to find exact colors used in the options by using “View Code”

      In an attempt to roughly gauge success criteria for W3C color contrast standards, I used Snag-It to capture an image, and then used Photoshop eyedropper to at least grab an approximation of the color.

      I then used Juicy Studio’s Color Contrast Analyzer to get a sense of color contrast among the options.

      Blue: Photoshop color picker for the background: #52accc Using White Foreground #fff (for the text)
      Results: Results for Luminosity Contrast Ratio

      The contrast ratio is: 2.58:1

      Fail: The luminosity contrast ratio is insufficient for the chosen colours (#52accc and #fff) (Needs large text to pass)

      Seaweed #15757a from color picker, #fff for text:

      Results for Luminosity Contrast Ratio

      The contrast ratio is: 5.44:1

      Passed at Level AA for regular text, and pass at Level AAA for large text: If the text is large text (at least 18 point or 14 point bold), the luminosity contrast ratio is sufficient for the chosen colours at Level AAA; otherwise, Level AA (#15757a and #fff).

    • _Redd 6:54 pm on October 1, 2013 Permalink | Log in to Reply

      Color comparisons continue to above:

      Pixel #59524c from color picker, #fff for text:

      Results: Results for Luminosity Contrast Ratio

      The contrast ratio is: 7.68:1

      Passed at Level AAA: The luminosity contrast ratio is very good for the chosen colours (#59524c and #fff).

      Ectoplasm #523f6d #fff for text

      Results:

      Results for Luminosity Contrast Ratio

      The contrast ratio is: 9.17:1

      Passed at Level AAA: The luminosity contrast ratio is very good for the chosen colours (#523f6d and #fff).

      …..more comparisons to follow

    • _Redd 7:00 pm on October 1, 2013 Permalink | Log in to Reply

      Comparisons continue to above:

      Sunrise #cf4944 as background #fff for text

      Results for Luminosity Contrast Ratio

      The contrast ratio is: 4.48:1

      Passed at Level AA for large text only: If the text is large text (at least 18 point or 14 point bold), the luminosity contrast ratio is sufficient for the chosen colours (#cf4944 and #fff).

      Vineyard #462b36 as background #fff for text

      Results: Results for Luminosity Contrast Ratio

      The contrast ratio is: 12.66:1

      Passed at Level AAA: The luminosity contrast ratio is very good for the chosen colours (#462b36 and #fff).

      …more coming

    • _Redd 7:03 pm on October 1, 2013 Permalink | Log in to Reply

      Color contrast evaluation continues:

      Primary #35395c as background, #fff as foreground (text)

      Results for Luminosity Contrast Ratio

      The contrast ratio is: 11.10:1

      Passed at Level AAA: The luminosity contrast ratio is very good for the chosen colours (#35395c and #fff).

      …summary to follow

    • _Redd 7:09 pm on October 1, 2013 Permalink | Log in to Reply

      Hi, Rian, I’m not sure my first entry got saved. To repeat from earlier first reply, I really LOVE the new MP6 theme, but also very happy to have some one ask for a check on color contrast.

      Below is repeating what I said in an earlier reply, so accept my apologies if the earlier reply shows up again.

      In an attempt to roughly gauge success criteria for W3C color contrast standards, I used Snag-It to capture an image, and then used Photoshop eyedropper to at least grab an approximation of the color, as I was unable to actually see CSS code for the exact colors.

      I then used Juicy Studio’s Color Contrast Analyzer to get a sense of color contrast among the options.

      Blue: Photoshop color picker for the background: #52accc Using White Foreground #fff (for the text)
      Results: Results for Luminosity Contrast Ratio

      The contrast ratio is: 2.58:1

      Fail: The luminosity contrast ratio is insufficient for the chosen colours (#52accc and #fff) (Needs large text to pass)

      Seaweed #15757a from color picker, #fff for text:

      Results for Luminosity Contrast Ratio

      The contrast ratio is: 5.44:1

      Passed at Level AA for regular text, and pass at Level AAA for large text: If the text is large text (at least 18 point or 14 point bold), the luminosity contrast ratio is sufficient for the chosen colours at Level AAA; otherwise, Level AA (#15757a and #fff).

      In short summary, the blue, although extremely attractive, does not provide sufficient color contrast to meet W3C guidelines for contrast. The seaweed and sunrise colors will pass if the text is large, and the rest are fine.

      Thank you so much for asking.

    • esmi 7:13 pm on October 1, 2013 Permalink | Log in to Reply

      I think the point to keep in mind here is that these would be user-selectable schemes (as I understand it), So as long as the default scheme passes minimum WCAG contrast levels, it really doesn’t matter what contrasts are present in the alternative schemes. Also, remember some dyslexics would welcome a very low contrast scheme.

      I’ve actually suggested that the color schemes shipped with the plugin (and later in core) include at least one high-contrast scheme for visually-impaired user and one very low contrast scheme for some dyslexics. This ability to provide schemes for different user groups is something that Helen & I have talked about (albeit rather wistfully) in the past. :)

    • Joe Dolson 7:13 pm on October 1, 2013 Permalink | Log in to Reply

      I think it’s important to note that these are not all of the themes; the primary MP6 theme, which David Kennedy has been reviewing, will definitely be included when MP6 is shipped; these other options are candidates as additional color schemes that will be available.

      Esmi has already suggested adding a high-contrast and a low-contrast color scheme to accommodate for low vision or dyslexic needs; voices might be helpful there: http://make.wordpress.org/ui/2013/10/01/mp6-color-schemes/

    • Rian Rietveld 7:23 pm on October 1, 2013 Permalink | Log in to Reply

      Thanks all for the quick response. It would be perfect if MP6 will be included with a few accessible colour schemes. @esmi, thanks for all your effort!

  • Joseph Karr O'Connor 4:07 am on September 30, 2013 Permalink
    Tags: , meeting notes,   

    Most of the time was spent discussing http://core.trac.wordpress.org/ticket/21334 3.7, grahamarmfield->helen, closed, Row actions are not always keyboard accessible. Helen Hou joined us for the discussion.

    1. When mouse hovers over a page/post row in main Pages/Posts screen ‘quick links’ appear. Suggesting that they also are made available for keyboard-only users and screen reader users.

    2. When using the QuickEdit panel the time/date controls have separate tabindex and no labels. Suggesting that the tabindex be removed from those controls, and that labels be used.

    Discussion centered around the need to reduce verbosity for screen reader users, while still making the controls available to them.

    It was decided to test the latest build and come back with a recommendation.

     
    • Graham Armfield 6:48 pm on October 1, 2013 Permalink | Log in to Reply

      I’ve tested the fix with the latest (I believe) version of NVDA and the quick links become accessible when focus is on the Post/Page Title. So that’s good. They are also not all listed by screen readers when the Posts/Pages list first appears.

  • Helen Hou-Sandi 9:21 pm on September 24, 2013 Permalink
    Tags: ,   

    Feedback on #21334: Row actions are not always keyboard accessible 

    I’ve made two commits so far to address the fact that row actions (that is, edit/quick edit/trash under each post’s title) only show on hover. I have two questions regarding this that I could your expertise on:

    1. In terms of CSS, this is controlled by the visibility property. My understanding has been that visibility: hidden does not get read by screen readers. If this is the case, then we may want to use an alternative method for show/hide. Are these row actions currently in a state where they are useful to screen readers or are they better off not being read (for now)?
    2. Right now the keyboard tabbing will only trigger them to show when in the same cell. Should this expand to whenever focus is within the row? I believe visually it is when hovering on the table row.

    Thanks!

     
    • PhilippeVay 12:28 pm on September 25, 2013 Permalink | Log in to Reply

      Hi,

      both display: none; and visibility: hidden; aren’t read by screen readers, that’s correct. There are now other CSS techniques that will also hide content but not on all screen readers (ex: height: 0).
      The well-named WP class .visually-hidden will move content off viewport so it’s still read by screen readers but not visible to sighted users with CSS activated: it’d be a good alternative to hide content only to sighted users.
      Useful or not here? I haven’t been active on WP for a while so I’ll have to take a look to these actions first :)

      Concerning keyboard and hiding content: I think there are 3 categories of disabled people that have different needs and habits.

      • blind people will use keyboard and a screen reader,
      • low vision people may use mouse and/or keyboard and a screen reader or not. The four combinations are possible
      • motor impaired will probably use a keyboard but no screen reader

      Screen reader may access rich information in an accessible table (related to header cells of a particular cell via scope – or id/headers – attributes) even if a link or button is off viewport while motor impaired wouldn’t be able to interact with this same table. So I think it’d be better to show all actions in the current row if one of the links has taken focus.

    • Joe Dolson 2:58 pm on September 25, 2013 Permalink | Log in to Reply

      I generally agree with Philippe.

      Keyboard tabbing should trigger the links, I think, whenever focus is in the row; that will maximize awareness of these options. It’s not critically necessary, but when it comes to being able to find and understand the options, this will be the better solution.

      For screen readers, just using the visually-hidden solution, so that the links are always available for screen reader users is, in my opinion, the best solution. It does run into the repetitive-link problem, but I honestly think that in this user interface that’s not really an issue; it will be more valuable to be able to have those links available in context.

    • Helen Hou-Sandi 2:02 am on September 26, 2013 Permalink | Log in to Reply

      Thanks so much for the quick feedback – based on the IRC chat, it seems that the solution that is in the current nightly might actually be for the best, due to lack of context for screen readers and the sheer number of links that would appear. Perhaps things can be improved in the future for screen readers in this regard, although these links are convenience and not exclusive to the area. For 3.7, let’s focus on getting it just right for keyboard tabbing. We actually need to get this done in the next couple days, so I look forward to any further feedback, but do note that there’s a chance that further improvements will have to wait until 3.8 if this drags on.

    • _Redd 7:23 pm on September 27, 2013 Permalink | Log in to Reply

      Hi Helen, from what I can tell from running a very brief test, the quick links menu is available upon the first visit to the post, and it allows you to get into the quick edit menu and perform edits, but once that takes place, the quick edit menu disappears and is no longer available to a screen reader (at least NVDA).

      Would you like access to my test site?

    • _Redd 8:36 pm on September 27, 2013 Permalink | Log in to Reply

      I’m sorry, Helen, I forgot to include an example of what I’m talking about. Here is the link to the site.

      Once again, we are all really appreciative of what you’re doing for us. You are the BEST!

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel