WordPress.org

Ready to get started?Download WordPress

Make WordPress Accessible

Updates from January, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • Joseph Karr O'Connor 6:27 am on June 20, 2014 Permalink  

    Accessibility Team Update: June 18, 2014 

    Visual Focus In Left Navigation

    Screenshot of admin left navigation showing Posts menu selected with New Post submenu selected

    Posts menu selected with indistinguishable darker black shading, Add New sub menu item selected with text in dark blue. Note that dark blue text against dark gray is hard to see.

    Color Alone

    Visual focus indicators for wayfinding are relied on heavily by some keyboard-only users. @helen notes the enhanced visual focus indicators now in trunk. Ticket #28267 needs a lot more work bringing the focus style to various places but one area that needs a smart solution is left navigation. Now we are relying on color changes which are, in some instances, too subtle. Indeed, color is not to be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

    Suggestions

    We discussed this for most of the meeting and here are some suggestions.

    • Helen reports that a blue glow does not look good
    • White outline around menu item with white outline also around selected submenu item
    • Reversing the colors with another undefined indicator element
    • Triangle to the left of main menu item and selected submenu item
    • Underline under main menu item and selected submenu item (might be mistaken for links)

    Solution Needed

    We need some suggestions for an elegant solution. Bear in mind that there are eight admin color schemes and any solution should take that into account. I have created ticket #28599 to work on this issue. A WordPress Accessibility Team shirt to the person who comes up with the adopted solution!

     
    • jebswebs 5:02 pm on June 20, 2014 Permalink | Log in to Reply

      Just wonder if one of the eight admin color schemes could be called High Contrast and use a yellow on black color set. I have been battling the gray on white and gray on black fight with multiple theme developers in multiple CMSs for several years. It would be curious to know how many users ever take time to change from the Default admin color scheme.

      • esmi 7:12 pm on June 20, 2014 Permalink | Log in to Reply

        Helen and I have talked briefly about this before. The idea was that, as the admin skinning system matured, there would be more opportunities to provide low and high contrast admin skins via plugins, if necessary. It’s certainly something I’ve been wanting to do for years.

    • esmi 7:08 pm on June 20, 2014 Permalink | Log in to Reply

      I’m a big fan of reversing background and foreground colors, so in the example screenshot you posted above, I’d want to see something like a blue background with black/dark grey text.. It’s got to really “pop” for sighted keyboard navigators. triangle indicators are very nice as added features for onhover but I’d argue that they’re too subtle for focus highlighting. Ditto for underlines. General rule of thumb: if you have to visually hunt for the currently focused element, then you need something else.

      • Joseph Karr O'Connor 9:35 pm on June 20, 2014 Permalink | Log in to Reply

        So you and @jebswebs support a high and a low contrast admin color scheme which is a different path from devising a solution just for the left navigation that persists through all color schemes? I’m very interested in this idea, wonder if enough people will discover the feature. I think we still need robust focus indicators throughout admin, but support additional accessibility color schemes.

    • David A. Kennedy 2:35 pm on June 25, 2014 Permalink | Log in to Reply

      As I’ve said in our previous team meetings, I’m in favor of a suitable baseline for all color schemes. Although, I love the idea of specialized high contrast themes in addition to that.

  • Joseph Karr O'Connor 3:57 am on June 12, 2014 Permalink  

    Accessibility Team Update: June 11, 2014 

    New Accessible Theme

    Joe Dolson is working on a new accessible theme for the Cities series using an innovative modular approach for accessibility by gathering up accessibility concepts into separate files.

    Joe says:

    “I’m explicitly placing all the accessibility-specific code into a11y.php and a11y.js, to make them easy to find. This is intended to be a useful resource for theme developers, so I want everything to be easy to find.”

    Also of note is skiplinks.js which fixes a bug in WebKit. Simply using an anchor link for the skiplink isn’t enough for WebKit, because keyboard focus will not follow visual focus without Javascript. Joe will be presenting this new theme in a session at WordCamp Chicago this weekend.

    Accessibility Theme Check Process Enhanced

    We are aware that a few themes that are not accessible have arrived in the theme directory with the #accessibility-ready tag. Perhaps the theme creators misunderstood the tag or copied it from another theme without thinking. We got a message from someone who knows accessibility that he bought a theme based on the fact that the free version has the #accessibility-ready tag. Expecting it to be accessible, he was disappointed. Contacting the theme creator he found out that they will be uploading a new free version without the tag.

    Joe Dolson on the process:

    “We’re still struggling with themes getting through the process without getting audited, but we have a recourse for this now. The official policy is to give the author notification that their theme needs to go through the accessibility-ready review to keep the tag, and that they have 72 hours to begin rectification – either by uploading a new version without the tag or by uploading a new version that will begin the process of meeting the accessibility-ready requirements. After 72 hours without a response, the theme will be suspended from the theme repository.”

    Unification of Visual Focus Indication

    It is essential to provide a visual cue to sighted keyboard-only users letting them know where they are on the page. There is no standard look for visual focus indicators. The issue is made more complex because user agents approach this in different ways. @helen talked with us last week and this week again about the fact that the visual look of focus indicators is not unified, and in some instances is not perceivable. For example, on the Media Library screen this is a screenshot showing “apply” button with dotted line focus indicator active and it is not perceivable. One tab press to the right of the “apply” button is the “All dates” select menu selected with a screenshot showing “All dates” select menu with blue glow and dotted line.

    The base look might be the approach taken by WebKit, a blue glow. A base look with more than one element is what we seek. Even if the color blue cannot be perceived there is still the glow. This week we have a goal of organizing the approach to the UI in such a way that the visual focus indicators are unified and perceivable.

     
    • _Redd 8:37 pm on June 18, 2014 Permalink | Log in to Reply

      Hi, everyone, regarding the Unification of Visual Focus Indication, and the meeting today (June 18), I found an example of what I was talking about with using icons to demonstrate a change of focus in the left-hand nav menu.

      http://tympanus.net/Development/IconHoverEffects/#set-1

      Here, the icons “reverse” dark and light areas, and also have additional visual indicators that show the item has received focus. A picture is worth a thousand words, and this example says it far better than I could.

    • _Redd 8:53 pm on June 18, 2014 Permalink | Log in to Reply

      Whoops! Follow Up!

      These icons undergo changes when hovered over, not when receiving focus. The idea of course is that we could develop css to perform similarly when the item receives focus.

  • 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

  • esmi 9:42 am on January 25, 2013 Permalink
    Tags: , ,   

    IRC Meetups 

    Most of the other WordPress groups have weekly meetings via IRC. Do you think this would be viable option for this group too? Does anyone have any difficulties accessing IRC?

    If we did have regular meetups, I’m assuming weekdays would be best — for half an hour or so between 19:00 and 21:00 GMT?

    Thoughts

     
    • GrahamArmfield 9:50 am on January 25, 2013 Permalink | Log in to Reply

      Sorry for my ignorance but what’s IRC?

      • esmi 10:38 am on January 25, 2013 Permalink | Log in to Reply

        Oh – sorry! Internet Relay Chat. You can use dedicated software like mIRC. There are also JavaScript browser interfaces like Freenode’s web chat and an increasing number of apps for mobile devices. I’m about to try using IRC999 for the iPad which, I understand, works well with VoiceOver.

    • GrahamArmfield 9:51 am on January 25, 2013 Permalink | Log in to Reply

      Re your second question – yes, weekdays are best.

    • ceo 11:39 am on January 25, 2013 Permalink | Log in to Reply

      I have no problem with IRC. I’m on it all day for work anyway. ;-)

      • ceo 11:40 am on January 25, 2013 Permalink | Log in to Reply

        Ok, not related, but the last two days (and I assume this may be related to being invited?) when I post a comment it gives me an “unknown error; comment not posted” message even though my comment has too been posted.

      • Joseph Karr O'Connor 9:03 pm on January 25, 2013 Permalink | Log in to Reply

        I will participate in IRC sessions, very smart idea.

    • Nelson 12:48 pm on January 25, 2013 Permalink | Log in to Reply

      I haven’t used WordPress’s IRC before, but I think using IRC in that time frame to discuss accessibility testing would be an excellent idea.

    • Sveta 2:31 pm on January 25, 2013 Permalink | Log in to Reply

      Chat is a good idea as long as its FULLY accessible to deaf participats like myself via text.

      • esmi 2:35 pm on January 25, 2013 Permalink | Log in to Reply

        @Sveta: It’s 100% pure text. I have hearing problems myself and absolutely hate video chat. :-)

        • Sveta 3:18 pm on February 6, 2013 Permalink | Log in to Reply

          Yes, but some chats include audio and people like myself can miss it if people use audio and don’t type.

    • esmi 2:32 pm on January 25, 2013 Permalink | Log in to Reply

      That could just be P2 (the theme) acting up. Sometimes it tells me that the network connection has been lost and then quite happily publishes my Post or comment. :-/

      • ceo 4:23 pm on January 25, 2013 Permalink | Log in to Reply

        Assuming this was to me? :-)
        Okies, well, I won’t freak out then about random posting errors that aren’t errors per se.

    • Ipstenu (Mika Epstein) 4:13 pm on January 25, 2013 Permalink | Log in to Reply

      esmi – You’re welcome to snag sfd for that. I mean, docs does. :) Or use UI, since I think they’re mostly in -dev now.

    • esmi 4:21 pm on January 25, 2013 Permalink | Log in to Reply

      Re-using UI would be a great idea. Who would I need to clear this with?

    • Joseph Karr O'Connor 9:45 pm on January 25, 2013 Permalink | Log in to Reply

      For our first IRC topic:

      From rachelbaker a new post:
      Theme Handbook Update Jan 24th on documentation page:
      http://make.wordpress.org/docs/2013/01/24/theme-handbook-update-jan-24th/

      It calls for contributions on many topics including accessibility. I just saw this and have not had time to read the Google docs associated with the project. If there is a need I will contribute and will ask for input from this group.

    • esmi 9:53 pm on January 25, 2013 Permalink | Log in to Reply

      I’ve already volunteered to contribute the the Theme Handbook (or pretty much any other handbook that is to have an Accessibility section) . I figured I’d draft something up and then throw it open to this group for comments, suggestions etc.

    • Joseph Karr O'Connor 11:20 pm on January 25, 2013 Permalink | Log in to Reply

      Excellent, if you want my help I’m ready.

    • Joe Dolson 8:55 pm on January 26, 2013 Permalink | Log in to Reply

      I could give a shot to IRC chat most week days.

    • Rian Rietveld 7:44 am on January 28, 2013 Permalink | Log in to Reply

      I’d like to join in too, for me on week days is also the best.

    • Amanda 6:02 pm on February 1, 2013 Permalink | Log in to Reply

      I would love to participate in some sort of WP accessibility meetup. Weedays would be best for me too.I’m using both Jaws and NVDA, and Window Eyes on occasion, have been woring with WordPress since 2005 helping people set up accessible websites with it, and have been looing for a way to contribute to WP development.

    • tady 11:39 am on February 6, 2013 Permalink | Log in to Reply

      Yup, I’d be all up for being involved in that. I haven’t been able to give constant feedback to the group due to work, and only dipping in and out of the group page, so I’d be glad to contribute to an IRC group more regularly.

    • Sveta 3:17 pm on February 6, 2013 Permalink | Log in to Reply

      I wonder what WordPress managers say about this? Is it possible to bring this issue to attention of managers?

      • esmi 3:37 pm on February 6, 2013 Permalink | Log in to Reply

        Sorry – I’m not following you. There are no WordPress managers per se. It’s a community project and we should be able to use the existing #wordpress-ui channel. I’m just about to post a suggested schedule.

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