WordPress.org

Ready to get started?Download WordPress

Make WordPress Accessible

Updates from February, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • 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 3:36 pm on September 5, 2013 Permalink
    Tags: ,   

    IRC Meeting: September 4, 2013 

    Yesterday’s meeting focused almost entirely on developing a global accessibility statement for WordPress. It was decided that the statement should be broad in nature, and that it will generally support accessibility with links to more specific information that this group maintains.

    The voluntary accessibility theme check process was mentioned, that process is nearly ready to launch.

    Much thanks to Mel Pedley @esmi for her guidance and leadership as team representative for the past 18 months. I will now serve as team representative.

    You can also contact us with words of encouragement or feedback on Twitter @WPAccessibility.

     
    • Amy Hendrix (sabreuse) 4:01 pm on September 5, 2013 Permalink | Log in to Reply

      So many thanks to @esmi for all the work repping this group! And congrats/welcome aboard, Joe!

    • _Redd 6:00 pm on September 5, 2013 Permalink | Log in to Reply

      Congratulations to Joe! I know we will all benefit from your presence here, as so many have already benefited from your other contributions to WordPress, such as your amazing Cities Themes project. And, I don’t have words strong enough or big enough to thank @esmi for her presence in the Accessibility blog. I think she was the first person I “met” in this group, and probably the one who figured most prominently in my education for accessibility in WordPress. She’s done more good than she knows. I have many times called attention to her input on these blogs and in the forums to others, and the guidance she provided, in turn, has impacted many websites for the better. Mel, we all can’t thank you enough.

  • esmi 12:39 pm on September 2, 2013 Permalink
    Tags: ,   

    IRC Meeting: August 28, 2013 

    The main focus of the meeting ( and the group) was still on one of our primary objectives — the development of a global accessibility statement for WordPress. After reviewing Drupal’s accessibility statement again, it was decided to begin work on drafting our own statement that can then be presented to the wider community for discussion.

    (More …)

     
  • esmi 2:58 pm on August 8, 2013 Permalink
    Tags: , , ,   

    IRC Meeting: August 7, 2013 

    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.

    (More …)

     
  • esmi 3:25 pm on May 23, 2013 Permalink
    Tags: ,   

    IRC Meeting: May 22, 2013 

    Another small but busy IRC meeting on #wordpress-ui where discussion focused on assessing the translate.wordpress.org site for possible accessibility issues.

    If you have a little spare time, please do try to contribute to the site feedback request. Any observation — no matter how small — is valuable. If you need some ideas on what to look for, please check out our Site Feedback Guide.

    #wordpress-ui log for May 22, 2013.

     
    • flick 7:54 pm on May 23, 2013 Permalink | Log in to Reply

      Thank you for the log. Am only just beginning to get acquainted with the Accessibility side of WP so every little helps. I am confused by the naming of GlotPress but perhaps it could be because I haven’t read enough about it. Is there a glossary somewhere one can refer to? Thanks.

      • esmi 8:20 pm on May 23, 2013 Permalink | Log in to Reply

        GlotPress is just a name — like WordPress, or BuddyPress. I think the problem we have here is that 3 different — but related — resources are all called “GlotPress”.

        Glad to hear that the IRC log was useful. We’d be more than happy for you to join in the meetups at any time.

    • flick 12:01 am on May 27, 2013 Permalink | Log in to Reply

      @esmi: Thank you for the welcome and for the clarification. I will be sure to try and attend an #irc meet up soon – just need to remember to put it into my Google calendar and be in :)

    • TDM 3:30 pm on May 28, 2013 Permalink | Log in to Reply

      Any idea when the next one will be ?

    • esmi 3:38 pm on May 28, 2013 Permalink | Log in to Reply

      Tomorrow – 19:00 UTC in #wordpress-ui

  • esmi 1:46 pm on April 26, 2013 Permalink
    Tags: ,   

    IRC Meeting: April 24, 2013 

    We had another lively IRC meeting on Wednesday.

    3.6 Post Formats

    It was previously decided that both the video and audio post formats could benefit from an ability to add links to captions (for videos) or transcripts (for audio files) and some preliminary investigations were started to look at the possibility of submitting patches. However, as there has been some concern about the release schedule for 3.6 and the possibility that Post Formats might be removed from the release, this has been shelved until we hear further.

    (More …)

     
  • esmi 12:14 pm on March 8, 2013 Permalink
    Tags: documention,   

    Accessibility for Theme Developers: First Draft Complete 

    I think I’ve finally finished! *gasp* Thank you to everyone who provided earlier feedback and jogged my memory.

    Is there anything on the completed page I need to re-word or explain in more detail?

    As previously, please post all feedback here rather than on the draft page itself.

     
    • Dane Morgan 4:21 pm on March 8, 2013 Permalink | Log in to Reply

      that content must:

      needs a ‘be’. Also with a list that each part concludes a thought, no : is required, use periods at the end of each item title to tie them to the beginning clause.

    • mrwweb 4:46 pm on March 8, 2013 Permalink | Log in to Reply

      This is a really great resource! Thanks @esmi.

      A few thoughts:

      1. Maybe I’ve been doing this wrong forever, but it seems that the “good read more” code snippet could be simplified a bit:
      <?php printf( __('%1$s – read more’, ‘theme_text_domain’), get_the_title() );?>
      I also wonder if this technique deserves mention. It’s weird but I’m planning on using it in future themes I build.

      2. There’s no mention of motion issues. Almost every slider I see these days has accessibility issues including slides advancing too quickly, text embedded in images without alt text, no keyboard navigation, no play/pause button provided, etc.. I wonder if those issues, particularly speed/motion,deserve mention.

      3. This could take people down a wormhole, but I wonder if citing appropriate WCAG standards might add a bit of muscle to the points.

    • esmi 6:09 pm on March 8, 2013 Permalink | Log in to Reply

      it seems that the “good read more” code snippet could be simplified a bit

      I added the extra variables so that developers could use the generated span to hide the first part of the link off screen – if that was preferred. Personally, I do think it reduces screen clutter by a fair amount whilst still supporting screen reader users.

      There’s no mention of motion issues.

      They’re under “Things To Avoid – Autoplay & Animations”.

      I wonder if citing appropriate WCAG standards

      I’d rather not get down to the level of citing specific WCAG criteria in the main body of the page for a couple of reasons:

      • I’m really wary of overwhelming those who are relatively new to web accessibility. Better that they implement some of the points in the document than run screaming for the hills vowing never to look at it again. ;)
      • I’d like to avoid leading people into a “checklist” mentality, if that’s possible. Ideally, we want developers to think first instead of making assumptions all of time, yes?
      • Frankly, WCAG 2.0 is enough to scare anyone!

      That said, I was wondering if I ought to include some more specific WCAG links in the General Resources section.

      • mrwweb 11:49 pm on March 8, 2013 Permalink | Log in to Reply

        Wow. Totally missed the autoplay & animations section. Not sure how. Sorry ’bout that.

        However, what this does make me think of is whether it might be worth adding a “common features with common accessibility problems” sections that references the relevant sections. I wonder if a theme developer would blow past “link text” but latch on to “read more links.” Same think with slideshow sliders. Of course this list couldn’t be exhaustive, so it might be more trouble than it’s worth and could lead to your fear of checklisting themes for accessibility, which I share.

    • _Redd 6:29 pm on March 8, 2013 Permalink | Log in to Reply

      Do you think a warning against using tables as layout for forms (or other) should be mentioned?

    • Sharon Wachsler 1:05 am on March 9, 2013 Permalink | Log in to Reply

      Wow! What a great resource this is. It covers a lot of ground, and I like how you use a few very basic concepts at the beginning to encourage developers to think along those lines and then also give lots of specific examples later of the way they are implemented.

      I also learned from this document. For example, I always spawn new tabs because I find that much easier for me when I use websites, but I didn’t know this causes a problem for people who use screen readers. (I’m not sure what to do about this. Maybe I will decrease my use of them a lot and then include a link to get back to the original post?)

      I liked the example of the Japanese cartoon sending kids to the hospital. It makes it very concrete. I have noticed that slideshows on autoplay are more and more common. My independent living center has an autoplay slideshow on their website now! [head::desk]

      A typo: “And do not play any sounds with the user’s express permission.” I think you mean “without” permission, yeah?

      Thank you for all your hard work and the care that went into this.

    • andyvaughn 7:59 pm on March 12, 2013 Permalink | Log in to Reply

      HTML5 longdesc attribute: Since this can fall under our umbrella, should we add this to the “theme development” section?
      (First public working draft today): http://www.w3.org/TR/html-longdesc/

    • esmi 8:17 pm on March 12, 2013 Permalink | Log in to Reply

      Nope. AT support for longdesc is very limited to non-existent. right now. I really wouldn’t bother using it — let alone ever relying upon it. Maybe re-visit it in a a few years to see if support has grown as HTML5 support increases?

    • fingli 9:42 pm on March 12, 2013 Permalink | Log in to Reply

      May I suggest Total Validator http://www.w3.org/2001/sw/wiki/TotalValidator as another useful tool for checking accessibility. From my experience with it I can say it makes correct checks (no false positive warnings) and they updated it regularly.

    • esmi 1:15 pm on March 13, 2013 Permalink | Log in to Reply

      Oh – yes! I’d forgotten that one. I recently tried it out on a large site audit and was pleasantly surprised just how well it performed. I’ll add it to our list of useful tools.

    • Rian Rietveld 2:46 pm on March 18, 2013 Permalink | Log in to Reply

      Hi @esmi, thanks for posting these excellent guidelines for theme developers!
      All these guidelines and tips are also very useful for plugin developers.
      I hope the developers of the major plugins and frameworks take the time to read this.

      Maybe a note at the top to encourage reading: everything that’s good for accessibility is good for SEO too ;)

      Some of my thoughts on the post:

      Move Validation to the top of the list ( if only plugin developers would validate, life would be so much easier..)

      Images:
      In stead of decorative images (null alt) write
      decorative images (alt=””)

      Readability:
      typo Tthe (second bullit)

      Form Markup:
      I didn’t know this: “any text that uses plain

      tags may be ignored”
      Can’t text be put in any other element then label or input inside a form?

      Readably:
      Quote: If you are using custom fonts, embed them in your theme so that you are not relying on a 3rd party site for font delivery.
      Maybe only say :
      “If you use a 3rd party site for fonts, check that the text is still readable if the fonts are not available.”
      The fact that some fonts are hosted 3rd party is no accessibility issue on it’s own. (I use Google fonts a lot.)

      The anchor link to the color blindness simulator doesn’t work.

      Cross-Browser Testing: Add Chrome to the list?

  • esmi 4:22 pm on March 7, 2013 Permalink
    Tags: , , ,   

    IRC Meeting: March 6, 2013 

    Another small but lively meeting. We also had the opportunity to welcome our newest member, @shaun_10up – a relatively new core contributor. I think we’ll be keeping him busy over the next few weeks! :)

    Custom menus

    Thanks to contributions from @lessbloat, @ceo and @quanin, we’re now seeing real, positive, progress on Trac ticket #14045. This greatly increases the chance of WordPress 3.6 being shipped with a more accessible custom menu system. Thank you for all of your hard work on this.

    (More …)

     
  • Graham Armfield 10:01 am on February 25, 2013 Permalink
    Tags: , , , ,   

    Add Media Panel – Accessibility Issues 

    I’ve raised this post as I feel that the issue of the Add Media panel accessibility needs some debate amongst the accessibility community.

    Last week I raised three WP trac tickets covering my take on the problems from the keyboard access, screen reader and VR aspects. They are: #23560 and #23561.

    The main problem as I see it is that it is not possible to select/deselect any of the media without using a mouse.

    The functionality primarily acts like a group of checkboxes – selecting one or multiple elements, with feedback that they have been selected. However, that is not how the functionality has actually been implemented – it’s a series of divs contained within an unordered list. There appears to be nothing to receive focus. There are links for each file, but the links appear empty although they are used to show the selected icon. These links are also initially invisible using CSS techniques that hide them from screen readers – hence the no tabbing into the images issue.

    Is the use of ARIA going to really be able to help here?

    When mouse users select an image they can update the attribute values for that image using the panel to the right – which updates its content automatically. Allowing keyboard users to quickly reach the attributes boxes would obviously be desirable – the alternative being tabbing through all the previously uploaded files.

    The media selector panel has been implemented with infinite scrolling, so on mature and/or larger sites with many images/files (I have one) the list of images gets bigger and bigger. From an accessibility perspective I’d favour paging over infinite scrolling, but what’s your take on that?

    Is this another area where bending the new functionality to include accessibility might be too much? Is this another place where an accessibility mode is going to be required?

    What do you think?

     
    • _Redd 2:24 pm on February 25, 2013 Permalink | Log in to Reply

      So, first of all, thank you for your breakdown as to exactly what is going on with the Add Media panel. I had no idea.

      1. I am not finding great support for ARIA in my other efforts. We should use it where ever possible, of course, but I think it is a mistake to depend on it.

      2. I am learning that, so much, too much, is mouse-dependent. It’s not just about making it accessible for the blind, it’s about the other users who can’t use a mouse, so this is something critical. How hard would it be to add a:focus to the CSS?

      3. While those who are blind may not need to see “images”, there is certainly a need to “see” the accessible pdf files, which are considered images. (Now I wonder if WordPress is stripping off, or blocking access from, the accessibility features that can be enabled in Adobe pdf files). So definitely, some sort of alphabetical sorting capability would be in order. That can’t be too hard with WordPress’s order_by functions, can it?

    • Donna W. Hill 10:00 pm on February 25, 2013 Permalink | Log in to Reply

      I recently purchased a domain from WP in order to have an online vehicle for promoting my upcoming novel, The Heart of Applebutter Hill. I am blind and use the Jaws screen reader and have both the IE9 and Firefox browsers. I have spent over a hundred hours in the past few weeks trying to figure out how to use WP efficiently and am starting to se some results. I’m not clear about the connection between WP.org and WP.com; some of the help files seem similar. If there is a connection, I thought you might be interested in my feedback. If not, I hope you will know to whom this information should be forwarded.

      The issue that has taken most of my time has to do with Media. My first suggestion for WP is to put together a concise Tutorial/Help topic addressing the definitions and description of the various types of images – header image, profile image, featured image, images inserted into posts and pages, attached and unattached images, permalink vs. File URL, the settings options for image size, which are editable, alternative options for uploading and inserting images and explainations of the difference between and the purpose of the file title, caption, alt tag and description. Currently, what WP has is incomplete, poorly described and scattered. That would help everyone. Beyond that, there should be a concise and easily located section about how WP currently works (or not) with access technology.

      When I realized that the Header image has such a weird width/heighth ratio, I opted for one of WP’s. In terms of uploading images, I find that the uploader, though squirlly, works. The option to upload media via e-mail is much better, but doesn’t work for all photos, though I haven’t yet figured out why.

      The next thing I got bogged down with was “Featured Image/Set Featured Image.” It’s so prominent in the image edit area, that I thought it was something that would show up inside the post or page. Once I realized that it was not, I moved on.

      Using the “Add Media” option from the edit field of a post or page brings up a page where you are supposed to be able to select and insert an image from those you have already uploaded into the body at the point of the cursor. This displays differently in IE and Firefox. In IE, there is a list of links, and Jaws says, “Link, deselect” for all of them, giving no indication what picture it’s talking about. In Firefox, there is a list which says it contains the proper number of image files, but only one is visible to Jaws. For instance, Jaws will say, “List of 9 items” and then, Link, Dog in Autumn Leaves,” followed by nothing else other than “list end.” For some reason, Jaws does read the file name in Firefox. Nevertheless, neither browser can actually be used to insert an image using Jaws.

      Since WP’s tutorials give this option pride of place, Jaws users may think it’s the only option. The best way to insert images in posts and pages that I have found is to use the alt m command from inside the edit field of the body of the post or page. It may seem at first that this option couldn’t possibly work. Using it causes Jaws to immediately jump out of forms mode, but WP apparently knows where the cursor was. Instead of going to the Media Library, “Alt m” opens a dialog in which WP requests certain information.

      The first thing it wants is the URL of the picture being inserted. It’s important to let screen reader users know that they should collect this information from the Media Library ahead of time and keep it in a document you can easily find offline. The next thing you need to know is that, despite the fact that in the Media Library the permalink for the image is right under the name and you really have to go on a hunt to find the File URL, it is the File URL that Word Press wants. Once it’s in the editfield and is Ok’d, another edit field appears requesting the alt tag. Even when the alt tag has been defined in the Media Library, it is not visible to Jaws in this edit field. I don’t know if it’s a Jaws or WP issue. Nevertheless, this is another use for the file information document, and when I copy the alt tag and paste it in, it works.

      The matter is further complicated for screen reader users by the fact that whether you use the permalink, which seems most obvious, or the File URL, which is correct, Jaws will recognize a graphic on the post or page, complete with alt tag. This promotes the illusion that you have been successful. Only when viewed by a sighted person do you find out that the permalink version is an empty box.

      The Media Library itself seems to be working for me better than you indicate in this post. The checkboxes at the top of each image’s section can be accessed with “x” or “shift x,” and one downarrow gets you to the link for the full list of edit options for that image. The search field also works.

      The other thing that would help navigation is to change the configuration of the major area of the Dashboard. If I downarrow through the page, I can tell that it is divided into sections with a major link followed by a list of corresponding links. It would be easier for screen reader users an no bother for anyone else to change this by making headings out of the primary link in each section — Posts, Pages, Media, Appearance, Settings and so on. If you don’t realize that “Media” shows up as both a section and under Settings, for instance, you can quickly get lost by using Jaws’ links list.

      • _Redd 1:07 pm on February 26, 2013 Permalink | Log in to Reply

        @Donna this feedback is amazing….thank you so much. For the record, as a totally sighted user, I also had trouble with understanding the featured image feature in WordPress. In fact, there is a ticket to that very problem for which developers are creating a fix.

        link to ticket for Featured Image

        Regarding the following:

        It would be easier for screen reader users an no bother for anyone else to change this by making headings out of the primary link in each section — Posts, Pages, Media, Appearance, Settings and so on. If you don’t realize that “Media” shows up as both a section and under Settings, for instance, you can quickly get lost by using Jaws’ links list

        I also encountered that same confusion as a totally sighted user, so I think there is real merit in what you are saying.

        @Graham @ceo I wonder if we can somehow work with UI team, docs team to address some of these problems? What are your thoughts on it?

        • ceo 1:27 pm on February 26, 2013 Permalink | Log in to Reply

          For the record, as a totally sighted user, I also had trouble with understanding the featured image feature in WordPress. In fact, there is a ticket to that very problem for which developers are creating a fix.

          I find it gets even more confusing because not all themes utilize featured images in the same manner. Some display them only on specific views while others display the image on all pages (post, archives, excerpt, etc.). Sometimes having a featured image and the same attached/inserted will show you a double image and other times not. This alone makes documenting what exactly a featured image is rather difficult since there’s no single treatment for what to expect depending on how the theme utilizes them.

          As to the links, that’s been brought up before (and I think there’s probably a ticket somewhere, though of course I can’t find one now). More descriptive links would be very beneficial given the sheer number of links present in the admin. And actually is somewhat part and parcel with the accessibility of the Media Panel, too, because when arrowing down you can move outside of the media window and not realize that what you are editing is actually back into your post or a link that will take you away from the edit screen entirely.

          • _Redd 1:32 pm on February 26, 2013 Permalink | Log in to Reply

            Great points, as always, ceo…

            …and I forgot totally about the theme issue……

            That said, I think this group, through its discussions, is in the process of nailing down the particulars and the details that developers need to develop accessible features. I’m sure learning a LOT just by being here. I’m betting the conversations here are the kernel to a next generation of WordPress that incorporates accessibility, not just add to it.

            Thank you (yet again) ceo

        • _Redd 2:01 pm on February 26, 2013 Permalink | Log in to Reply

          @graham @ esmi @ceo @joe and anyone else involved in the accessibility efforts, regarding Donna’s recommendation:

          The issue that has taken most of my time has to do with Media. My first suggestion for WP is to put together a concise Tutorial/Help topic addressing the definitions and description of the various types of images – header image, profile image, featured image, images inserted into posts and pages, attached and unattached images, permalink vs. File URL, the settings options for image size, which are editable, alternative options for uploading and inserting images and explainations of the difference between and the purpose of the file title, caption, alt tag and description

          I have to put together a tutorial for my workcenter on just these items. Let’s talk (maybe in IRC meeting) whether I could volunteer to help out with this, or coordinate on some level to assist. We could accomplish multiple tasks simultaneously; getting a tutorial out there, while incorporating accessibility issues.

          My only concerns would be my own competence (or lack of it), and whether or not I would be stepping on someone else’s territory. I absolutely rescind any request to do this if someone else is already working on it, or has plans to.

    • esmi 3:05 pm on February 26, 2013 Permalink | Log in to Reply

      A tutorial would be better handled by the Support group as it’s not really accessibility-specific. In fact, there might already be something available in the new User Guide.

    • _Redd 4:15 pm on February 27, 2013 Permalink | Log in to Reply

      Did you see the awesome ticket here?
      Hooray!

      3.6-Nav Menus Tracking Ticket

      It references ticket 14045 Give the menus page an accessibility mode option, like the widgets screen.

      Terrific, super! Appreciation for this!

    • Leslie Goldman 3:28 pm on March 4, 2013 Permalink | Log in to Reply

      I updated to the latest version. I cannot figure out how to resize my photos. I am up against a conference deadline. I had no problem the a previous version where I could designate what size photo I wanted. I am very stymied my work now. How to you edit the size of a photo for insertion into a post or pages?

      http://plantyourdream.net/?page_id=15535

  • esmi 12:29 pm on February 14, 2013 Permalink
    Tags: , links   

    Spawning New Windows/Tabs 

    Sorry for the flurry of posts but there’s an important discussion going on in re-opened Trac ticket #20839. The current discussion is focusing on:

    1. Should the “Visit plugin site” offsite link (in Plugins → Installed Plugins open in a new window/tab? (A no-brainer?)
    2. The best way to pre-warn users of an offsite link

    Some practical suggestions for the latter might come in very useful right now.

     
    • _Redd 1:07 pm on February 14, 2013 Permalink | Log in to Reply

      From a student use perspective, it seems that no matter WHAT I do to flag a link, students will simply use a “back button” on the browser. If they click on the link and it’s not something they want to see, they just hit a back button, not a bread crumb. Opening in a new window robs them of that back button functionality

      And, of course, I’m not saying its right or wrong, I’m just passing an observation when I ran tests with students. My carefully crafted links were ignored….

      As far as perhaps using icons to signal a way back home, I was stunned that the little “home” icon meant nothing to them….they just thought it was a decoration.

    • esmi 2:10 pm on February 14, 2013 Permalink | Log in to Reply

      Opening in a new window robs them of that back button functionality

      Exactly! And when you're a switch user, that means you're effectively left stranded in the new window. And the never-ending problem with trying to use conceptual icons is that not everyone "gets" the concept that you're trying to imply.

      • _Redd 2:12 pm on February 14, 2013 Permalink | Log in to Reply

        What is a “switch” user?

        • esmi 2:54 pm on February 14, 2013 Permalink | Log in to Reply

          Switch access. Think of it like a single button tab key. Used by people with severe mobility problems and can be operated by the hand, foot or elbow. Switch users often use onscreen keyboard software to carry out actual typing (eg completing a form) but, in all other areas of web surfing, can be considered as sighted keyboard navigators with access to just a TAB key.

    • GrahamArmfield 12:12 pm on February 15, 2013 Permalink | Log in to Reply

      @esmi my view is that links should ideally never open a new window, even on links that point to external sites – you should always give the user a choice.

      There are times however when that may break a transactional flow – eg creating a payment on an online banking site, and it may be desirable for a new window/tab to be opened.

      But how to warn users if a link poitns to external site and/or is going to open a new window?

      An icon with an appropriate alt attribute would work for screen reader users as long as it was part of the link. However, yours and @_Redd‘s comments about people ignoring or not understanding visual icons is so true.

      I would not recommend using the title attribute – that is only guaranteed to work for mouse users, and the duplication of data is not always welcomed in screen readers that do voice title attributes – either by default or as a result of user settings.

      • esmi 12:32 pm on February 15, 2013 Permalink | Log in to Reply

        how to warn users if a link poitns to external site and/or is going to open a new window?

        Ideally, in clear text as part of the link text itself.

        yours and @_Redd’s comments about people ignoring or not understanding visual icons is so true.

        One possible way around this is to incorporate a warning message at the top pof the relevant page along the lines of “Please note that links in this page highlighted by [icon image] will open in a new window”.

        or as a result of user settings

        It’s long been my understanding that experienced JAWS users turn off its Verbose mode, so will not hear any title attributes. It could be argued that is their choice and that developers should not be responsible if they (the devs) are using correct & appropriate markup. But there’s no suh “get-out” when it comes to sighted keyboard navigators — such as switch or voice recognition users,

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