WordPress.org

Make WordPress Accessible

Updates from November, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • Graham Armfield 4:52 pm on November 30, 2013 Permalink
    Tags: , , aria-hidden, i18n,   

    Patches provided for #25459 – Meaningful links in Admin 

    I’ve added two patches to trac 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.

     
  • Graham Armfield 11:30 am on November 28, 2013 Permalink
    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?

     
    • Rian Rietveld 3:23 pm on November 29, 2013 Permalink | Log in to Reply

      Hi Graham,
      The addition the title attribute to the element img was removed a few versions of WordPress ago, which is a improvement to my opinion.

      I use the title only for labeling the images in the Media Library, yes, maybe image name is a better description for that input field.

      And it seems logical to add the images name into the alt field if the alt field is empty, but that can result in alt texts like IMG_123. Maybe the best way is to leave the alt text empty unless a user entered a value there.
      An alt=””is always better than an alt=”IMG_123″.

      Rian

  • Joseph Karr O'Connor 5:59 am on November 22, 2013 Permalink
    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
    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.

     
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
Skip to toolbar