WordPress.org

Make WordPress Accessible

Updates from February, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • Cyndy Otty 7:30 pm on February 28, 2013 Permalink
    Tags: ,   

    Add Media Accessibility Summary 

    Following up on the original post about the Add Media panel, here’s a quick rundown of the functionality issues with screen readers:

    • Cannot select images from Media Library.
    • Media Library images display in list either without description/title (IE) or only the first image is seen within the list (Firefox).
    • A newly uploaded image can be deselected, but no other images can be selected in addition.
    • Cannot activate the Select Files link to upload image in Internet Explorer. (Works in Firefox.)
    • Form fields lack description; show as “unlabeled” in Internet Explorer.
    • Moving through the media panel can take the user (unknowingly) back into the edit screen.
    • Upon “re-entering” the media panel (see previous bullet point), form fields and links no longer seem to work.

    I’m sure there are other things that can be added to this list that I’ve missed. (Feel free to edit this as necessary, @grahamarmfield.) Unfortunately, while compiling this list my JAWS went berserk, giving me a bunch of installation errors and then my computer crashed.

     
  • esmi 2:54 pm on February 28, 2013 Permalink
    Tags: , , ,   

    IRC Meeting: February 27 2013 

    As usual, we had a lively meeting. Thanks to all who attended.

    Custom Menus

    The accessibility of custom menus in WordPress 3.6 and its related Trac ticket continued to be the main topic of conversation. This is undoubtedly going to be a very difficult area to get just right — not only in terms of the coding approach but also due to the problems of ensuring that screen reader users are presented with a meaningful construct when they try to manipulate menu items. Because of this, it was felt that there was a real danger of theoretical discussions taking priority over the development of prototypes. To try and avoid this, @GrahamArmfield and @lessbloat have agreed to take the lead together on developing prototype solutions.

    Add Media Panel

    @GrahamArmfield recently raised some concerns over accessibility issues within the current Add Media Panel and we decided to progress further with this. @ceo agreed to post a summation of the issues faced by some screen reader users shortly. Some possible new options were suggested such as an ability to tag images and filter the library by tag or an option to filter the library by upload date. Both may offer some benefits to users trying to locate a specific file in a large library when they are unable to “see” the images in question.

    Join Us

    Finally, a reminder that we are still a relatively small group of active members (although we have 156 people subscribed to this blog by email). We do need more active members – both technical and non-technical. So do please consider joining the group.

    #wordpress-ui log for February 27, 2013

     
  • 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

  • Jen 5:05 pm on February 21, 2013 Permalink
    Tags: captioning, transcripts   

    Captions on WordPress.tv 

    Hey folks. I posted the long description on the docs blog since they’re the product team responsible for all the text stuff: https://make.wordpress.org/docs/2013/02/21/hello-docs-folks-theres-a-new-project-set/

    We’re adding closed captions to wordpress.tv videos, so will be recruiting volunteers to create caption files (and others to review them for accuracy). The feature is ready and will be launched quietly on Monday. Will need a volunteer to head up the captioning corps (so to speak) under the aegis on the docs team. If anyone here is interested, please head over to the post linked above to express interest.

    Thanks!

     
    • Sveta 6:10 pm on February 21, 2013 Permalink | Log in to Reply

      That’s great – thanks for posting! There are also certain captioning guidelines to follow – you need not to just to make sure to fix typos and add punctuation, but also add speaker identification and sound descriptions and music lyrics. And videos need to have both captions and transcript like this – http://uxmas.com/2012/ux-trends-for-2013.

      This video has both captions (not auto captions – they are optimized by humans) and an HTML transcript.

      For more information, please check my website on http://www.audio-accessibility.com/solutions and feel free to contact me with more questions.

      I am happy to help with training volunteers about best practices and also to check for captioning quality.

    • Sveta 6:11 pm on February 21, 2013 Permalink | Log in to Reply

      I also presented at a WP meetup about accessibility: http://www.youtube.com/watch?v=6sTYOTB8hC8

    • Joe Dolson 9:41 pm on February 21, 2013 Permalink | Log in to Reply

      That’s great news, Jen — this will really be a benefit to that aspect of the WordPress ecosystem!

    • Joseph Karr O'Connor 5:07 am on February 22, 2013 Permalink | Log in to Reply

      Crowdsourced captions by Amara http://bit.ly/YKqBxf – I have not used this service, only became aware of it recently.

      • GrahamArmfield 11:51 am on February 22, 2013 Permalink | Log in to Reply

        I have used the Amara tool and it’s very useful. It works especially well with YouTube videos.

        An issue we may have here is for volunteers to be easily able to import the wordpress.tv videos into Amara to allow the easy creation of captions.

        I’ve had a look at an example page http://wordpress.tv/2013/02/14/andrew-nacin-y-u-no-code-well/ and the video itself id not directly referenced in the HTML, but is incorporated with javascript I believe.

        Buried within the javascript is reference to the actual video file – which is: http://videos.videopress.com/4RTgidPY/andrew-nacin-y-u-no-code-well_dvd.mp4

        If you navigate to Amara you will find it is possible to import the video – yay! See: http://www.amara.org/en/videos/XWy17TMwsvzl/info/

        So it would appear to be possible – as long as volunteers know where to go to find the path to the video.

        When captions have been made in Amara they can be exported and there are a number of different formats available. I guess the documentation team need to specify the format of the captions required – and hopefully there’ll be a match. I’d also be curious to know if the captioning supports multiple colours – some formats allow this and it helps to visually differentiate speakers. Not sure that colours can be added directly in Amara though.

        There is another online tool called Subtitle Horse (http://subtitlehorse.com/) that I’ve used a few times in the past. It’s a little flaky and not quite as whizzy as Amara but it can export in a larger number of formats with some flexibility. A neat feature is that you can use Subtitle Horse to convert caption files between formats by importing the caption file directly.

        This latter feature has helped create captions for an accessible media player that I’ve experimented with recently which is very finnicky about formats.

        • Jen Mylo 3:06 pm on February 22, 2013 Permalink | Log in to Reply

          As mentioned, the feature will not be turned on until Monday. When it is, there will be simple links to grab the file URL and to upload the subtitle file.

        • Jen Mylo 3:39 pm on February 22, 2013 Permalink | Log in to Reply

          To clarify my first comment reply, there will be another link to video file on the screen where you go to upload subtitle files. There were/are already direct links to the video files on each screen, you don’t need to dig through javascript at all. To the right of each video in the metadata column there’s a section like this:

          DOWNLOAD
          MP4: Low, Med, High
          OGG: Low

          where the direct file URLs can be grabbed easily.

      • GrahamArmfield 11:58 am on February 22, 2013 Permalink | Log in to Reply

        I have also posted a question on Jen’s original post on the Docs blog about whether the player on wordpress.tv was going to become keyboard accessible when the captions facility is added. It appears not, but that could/should be a future enhancement in my view.

        • Jen Mylo 3:08 pm on February 22, 2013 Permalink | Log in to Reply

          As I stated there, making publicly available content (the videos) accessible is a totally different project than making private company’s application (the VideoPress player) accessible. Never said it shouldn’t be done, but it is far outside the scope of this project.

          • GrahamArmfield 9:31 am on February 25, 2013 Permalink | Log in to Reply

            Thanks for clarifying that Jen.

            When the team comes round to looking at the accessibility of the player itself can I suggest that they might like to investigate the accessible player that has been built by Nomensa (a UK-based agency).

            They have made the player freely available and it is discussed here: http://www.nomensa.com/services/accessibility-and-inclusive-design/accessible-media-player and can be downloaded from GitHub here: https://github.com/nomensa/Accessible-Media-Player

            I have used the player on one site I’ve built (instatiated as a WP plugin) and it is fully keyboard accessible and provides good feedback for screen readers. It also supports caption files too (ttml).

            The player itself is built using jQuery so should be quite easy to configure if required.

            • Sveta 3:29 pm on February 28, 2013 Permalink

              Graham – no matter what player is used, there are 2 important requirements for captions:

              video can be viewed with captions on any device and not just computer

              captions should follow styling guidelines. It needs to be 100% verbatim, 100% error free, include proper punctuation, speaker identifications, sound descriptions, etc.

              captions should have good contrast, I.e. showig white or yellow letters on black bars.

              all videos should have BOTH captions and HTML transcripts below a video. Deaf-blind users cannot see captions via raised Braille, but they can see HTML transcripts below videos. HTML transcripts are also useful for users of mobile devices with slow Internet connections where its hard to view videos. And transcripts are also useful to be skimmed before deciding whether to watch long videos with captions.

      • Jen Mylo 3:05 pm on February 22, 2013 Permalink | Log in to Reply

        Yes, as noted in the post I linked to, Amara is the service we are using.

    • Sveta 3:24 pm on February 28, 2013 Permalink | Log in to Reply

      I wonder if WordPress TV player can be viewed with captions on any devices, including phone? I would like to read captions anywhere and not be limited to a computer only. YouTube and LongTail offer those options, for example.

  • Cyndy Otty 2:25 pm on February 21, 2013 Permalink
    Tags: , , , , ,   

    IRC Meeting Summary: 20 Feb. 2013 

    As evidenced by our small group at yesterday’s meetup, I want to first remind you all that we could very much use new members! Whether you are a developer and very technical or merely a writer with special needs, we would certainly welcome you to join us. Anyway, despite our numbers and lack of a formal agenda, our main discussion was on two topics that will be our primary focus presently.

    Custom Menus

    As the trac ticket concerning design changes to the Custom Menu has been closed, we discussed centering accessibility discussion around the reopened trac ticket #14045. The proposal is for an accessibility mode screen alternative like that which the Widgets page utilizes. We also have a post devoted to this topic here as well for your consideration and comments.

    Twenty Thirteen

    Feedback is strongly requested from an accessibility standpoint on the new default theme Twenty Thirteen, which is currently being developed. You can check out the theme here at the Twenty Thirteen demo site and please report any feedback you have.

    The full log of yesterday’s IRC meeting can be found here at #wordpress-ui logs for February 20, 2013.

     
  • esmi 5:03 pm on February 20, 2013 Permalink
    Tags: , , ,   

    Twenty Thirteen 

    Development on the next default theme — Twenty Thirteen — has now reached a point where our feedback is needed. You can see and use the theme (currently still in alpha) at its own Twenty Thirteen demo site.

    Please post all feedback here. If you are using assistive technology to browse the demo site, please indicate exactly what software you are using — including the version number, if possible.

    Come on, people. If you want a truly beautiful example of an accessible WordPress default theme, now is the time to point out any issues and support the theme’s developers.

     
    • esmi 5:06 pm on February 20, 2013 Permalink | Log in to Reply

      I’ll kick off…

      I’ve been looking at the theme from the viewpoint of a sighted keyboard navigator using the TAB (or equivalent) to move around the demo site.

      Keyboard Navigation
      Like the skip menu link but some focus highlighting on links right across the theme is desperately needed. On post title links with the pale/yellow backgrounds (standard, aside, chat & gallery formats), I’d suggest changing the background color to #f24b12. On the orange background for video & audio formats, try #fccb27. On quote posts, maybe something like try #fccb27 for the background and #141412 for the text.

      On the next/previous post navigation, perhaps replicate the hover CSS image change but definitely provide highlighting on the link itself the link text — maybe try #fccb27 for the background and #141412 again?

      Given the range of colors being used for different post formats (which I love, by the way), we need the currently focused link to really “pop”. Otherwise, it’s far to easy to get “lost” as soon as you move into the page.

      Contrasts
      Link contrasts generally need improving. For example links in standard posts (#f94a0a on#fff) have a link contrast ration of only 3.5:1 instead of 4.5:1. Change the link text color to #d93f08 & that issue is solved. Ditto the text in the footer where the ratio is only 3.1:1. Try #62605b for footer text instead.

      Other Concerns
      Links are not immediately obvious in status or quote posts. You have to “mouse scrub” the post content area to “discover” the links as their text is too close to that used by the plain text. The link text wither needs changing or those links need to be underlined (maybe with the underline removed on hover?).

    • GrahamArmfield 5:29 pm on February 20, 2013 Permalink | Log in to Reply

      Also from a sighted keyboard perspective (and from screen reader) I’d like to add that the horizontal primary menu has sub items in some places. But these do not become visible when the top-level menu item is tabbed to.

      In my view the sub items should dropdown on focus or else there is a real danger that entire parts of certain sites could be ‘hidden’ to keyboard users if the site owner has not provided other ways of navigating to sub-sections of the site.

      I echo your comments about more visible focus and links in general.

      • ceo 5:52 pm on February 20, 2013 Permalink | Log in to Reply

        I can second this using JAWS 9.0 as a blind person. In Firefox the navigation menu itself seems to be entirely skipped over. I can see the links within the link list option mode, but moving through the page itself I can’t find the menu. (I see the “skip to content” and then “search” and the actual menu is not there…) I do see it in Internet Explorer, but as Graham mentions, the submenu is essentially hidden.

      • esmi 6:55 pm on February 20, 2013 Permalink | Log in to Reply

        In my view the sub items should dropdown on focus

        I’m very much in two minds about this. If the sub items did drop down on focus, then we risk forcing people to tab through a whole stack of links unnecessarily. I have seen so many massive menus on the WPORG support forums (featuring 50 or more sub-menu links) that would be nightmare to navigate through.

        In an ideal world, my preference would be for no sub-menu dropdowns for keyboard navigators but a “pages in this section” sub-menu within each main menu page. But sadly, I think the latter could be outside the direct remit of a theme as core doesn’t offer much of use here — especially when you add in custom menus.

        • GrahamArmfield 4:13 pm on February 21, 2013 Permalink | Log in to Reply

          Providing multiple ways of accessing content on a site is of course very important – and one of the WCAG2 guidelines. But, I fear, that it is something that doesn’t always happen.

          I use functionality just as you suggest on many client websites that I’ve done, and I even have a plugin that can be used as widget called Child and Sibling Pages which does just that. It’s not ready for general release yet but I can make it available to others if requested. It’s current limitation is that it relies on strict page hierarchy which I tend to do for clients. So it may not show the ideal selection – either too much or too little.

          I guess the ideal solution here would be a way to hook into an appropriate custom menu to pull out an appropriate part of the page hierarchy. Maybe: 1) search for me in custom menu 2) If found, pull out siblings and children from that menu and list accordingly. 3) If I can’t find myself show nothing.

          I’ll have to check if there’s a way of accessing a custom menu structure from outside.

          In the meantime I favour showing the submenu items on hover for the reason I outlined above. When presenting about accessibility I use this site as an example: http://www.crowncourtchurch.org.uk/ You can see it’s based on 2010 and there are dropdown menus. However, because the menus aren’t keyboard accessible whole swathes of the site can’t be reached.

    • tady 5:50 pm on February 20, 2013 Permalink | Log in to Reply

      Ok, from a fully able user’s perspective, the primary thing I notice is the “Skip to content” link is really positioned all wrong on tabbing. It’s appearing over the primary nav.

      Also there appear to be a HELL of a lot of JS libraries and embedded styles in the header. Is there really an need for all these?

      No title attribute on PopSci image. Not coded in or not included in media library?

      Pretty much the same observations as Graham and Esmi. Some UI issues on Android smartphone, but flagged those in trac.

      • esmi 7:13 pm on February 20, 2013 Permalink | Log in to Reply

        the “Skip to content” link is really positioned all wrong on tabbing. It’s appearing over the primary nav.

        Well spotted. Shifting it up a minimum of 55px would help with that.

      • Konstantin 1:00 am on February 21, 2013 Permalink | Log in to Reply

        there appear to be a HELL of a lot of JS libraries and embedded styles in the header.

        They are wp.com specific and not part of the theme.

    • Sveta 6:30 pm on February 20, 2013 Permalink | Log in to Reply

      The video shown is not captioned and transcribed as required by web accessibility guidelines – http://audio-accessibility.com/solutions/best-practices/make-captions/.

    • _Redd 6:48 pm on February 20, 2013 Permalink | Log in to Reply

      The theme is GORGEOUS. I am in love. Be still my beating heart. I want it I want it I want it.

      That said, navigation is a problem, and the reasons why have already been outlined above by those more expert than me.

      And, unfortunately, as much as I love that color orange, burnt orange is one of the hardest colors in the universe by which to embed text with sufficient contrast of ANY color. Contrast is a problem throughout, but In particular, when the links are hovered over, the color becomes too light for perception among many viewers, even against the white background.

      I’m concerned about the setup for search. Even as a sighted user, one has to exactly hit the search icon, rather than tab into a box, and that will create problems. First, it presumes/assumes that people understand that the icon “means” search, and I can tell you that a lot of people just think it’s a decoration, not a cue to search. Secondly, there’s a presumption that the user doesn’t have any motor skill problems with their hands to get to that search icon. The “target” is too small.

      Handling search is one of the most critical things ANY site can have, because a modern user just doesn’t have the patience to look at links, indexes, or whatever. If search isn’t first and last in visibility and usability, users will just leave the site. At least, the young ones will.

      Again, though, the theme is GORGEOUS–I really, really love it. There’s problems with functionality as far as getting around the site, but hey, there are ALWAYS problems…and the WordPress developers have always been awesome at solving anything. I know this thing is going to knock it out of the ballpark! And, the theme is so beautiful, it makes you want to do anything in your power to make it work….

      • GrahamArmfield 7:02 pm on February 20, 2013 Permalink | Log in to Reply

        Haven’t had a chance to test with Dragon yet but I’d imagine that directly selecting the search box might be difficult. It’s never a good idea to force VR users to rely on tab commands or moving the mouse pointer about.

        • esmi 7:08 pm on February 20, 2013 Permalink | Log in to Reply

          Using what browser? As I understand it, Dragon + IE (the recommended set up) results in the user having numbered links that they can use. If it’s a non-IE browser… well, that’s user choice and outside of the remit of a theme,.

      • esmi 7:06 pm on February 20, 2013 Permalink | Log in to Reply

        burnt orange is one of the hardest colors in the universe by which to embed text with sufficient contrast of ANY color.

        I think it’s still just possible though. 🙂 And I think the theme could be “accessified” without too much disruption of the current color scheme with a bit more tweaking.

        Even as a sighted user, one has to exactly hit the search icon, rather than tab into a box, and that will create problems.

        Not sure I agree with this. I had no problem tabbing into the search input box (which expands nicely on focus) and, at 34 x 37px by default, I don’t think the search icon is too small — although a few more pixels padding to the left might be nice — and it zooms nicely too.

        it presumes/assumes that people understand that the icon “means” search

        I’d argue that it’s a reasonable assumption to make — particularly when supported by its placement (most users will look in the upper right area for a search box, in my experience).

    • GrahamArmfield 7:03 pm on February 20, 2013 Permalink | Log in to Reply

      Mel I know there was a post about 2013 theme on another board originally, will you be collating all the responses on here for the Core/UI team?

    • esmi 7:16 pm on February 20, 2013 Permalink | Log in to Reply

      I wasn’t aware of any other discussions. Link?

    • esmi 9:15 pm on February 20, 2013 Permalink | Log in to Reply

      I’d argue that the other thread is really more on general design issues and introducing the theme (and the principles behind it) generally. Lance Willet (who is part of the 2013 design team) is specifically looking for a11y feedback from here.

    • David A. Kennedy 4:09 am on February 22, 2013 Permalink | Log in to Reply

      First off, the theme looks and feels fantastic. It really has more personality than some of the past default themes (but still fits with them nicely) and I love the focus on blogging.

      I’m approaching this as a sighted user using Apple’s Voiceover with Chrome and Safari. I also did some light testing with the Wave Toolbar.

      I’m also guessing we’re not shooting for 100 percent WCAG 2.0 standards, so I’m aiming to be more pragmatic than anything.

      Links
      I generally like to see links underlined with text-decoration or have some kind of border in the main content area (or in paragraphs at the least), but I realize this might not be in the design aesthetic.

      I’d like to see the “Continue reading” and excerpt links get coupled with titles so they have more meaning. For example, “Continue reading “My Awesome Blog Post” > Generic read more links aren’t that helpful, generally speaking.

      Link Focus
      It’s very good overall, but I’d like to see:

      Focus styles similar to hover on the .main-navigation.
      Focus styles similar to hover on the .page-links.
      Focus styles similar to hover on the .nav-links.
      I’ll echo Graham’s comments about the sub-items in the .main-navigation. I’d like to see them become visible on focus.
      I’d like to see linked images get a more prominent hover/focus treatment. Maybe a 1px or 2px border.

      The .page-links and .nav-links are especially hard to see the focus because they are already the orange color, matching the focus indicator.

      Text Size
      Lots of people use page zoom to increase font size if need be, but I’d love to see the theme move away from pixels for font sizing and to a fluid approach with percentages or ems, making the content more flexible if need be. This would also harmonize well with the responsiveness of the theme.

      Forms
      I got an error from Wave Toolbar about two form labels associated with the search for, but glancing at the source code, I think that’s a false error.

      Let me know if you all have any questions. I might dig in a bit deeper this weekend. This is really is a great effort. I’m excited to see all this feedback and pumped that Lance and company are looking for it. There’s awesome stuff going on with accessibility and WordPress!

    • Michael Boer 7:09 pm on February 27, 2013 Permalink | Log in to Reply

      Twenty Thirteen is very nice, but adding a few standard WordPress widgets to it is all it takes to spoil it. For example, widgets like Categories and Archives raise red flags in the WAVE toolbar. Patches to fix this have been available for more than 6 months, but are still “awaiting review,” right? See: https://core.trac.wordpress.org/ticket/18650 What does it take to get WordPress to review a patch that relates to compliance with Section 508?

    • esmi 7:33 pm on February 27, 2013 Permalink | Log in to Reply

      Any issues with core widgets are outside of the remit of the theme and should be dealt with separately. No themes should ever be forced jump through hoops to patch a core issue. The problem needs fixing at the source.

    • C0BALT 8:30 am on March 4, 2013 Permalink | Log in to Reply

      If you use a plugin like this which hides the admin bar after a certain amount of time on the front end if you are logged in…
      Auto Hide Admin Bar
      https://wordpress.org/extend/plugins/auto-hide-admin-bar/

      then the new twenty-thirteen theme toolbar is offset by 16 or so pixels and shows a hole between it’s top and the top of the browser.

    • esmi 11:53 am on March 4, 2013 Permalink | Log in to Reply

      That’s not an accessibility issue. You need to raise this with the theme’s development team directly.

  • Graham Armfield 5:47 pm on February 15, 2013 Permalink  

    Creating Custom Menus 

    There is a lot of discussion and design going on at present concerning the changes that are being made to the Custom Menu Builder for WordPress 3.6. These discussions can be followed via trac ticket #23119.

    But as part of that work the Custom Menu Builder needs to become easily accessible to those who can’t use a mouse, or who are using screen readers or speech recognition software.

    During our IRC sessions this week and last we touched on potential solutions. So far the solutions have boiled down to:

    1. Use a separate accessible version in a similar way to how the accessible widgets functionality works.
    2. Ensure that the rebuilt functionality, which will almost certainly feature drag and drop contains and generates enough information to allow easy manipulation by those using assistive technology.
    3. Ensure that the markup of the solution externalises enough information about hierarchy and makes influencing it easy.

    But we need some more input on how this functionality could be deployed accessibly.

    Although the widgets method is usable, could it be better? If so, how.

    Could a drag and drop solution with ARIA help really work for blind users?

    Please feel free to comment with any ideas you may have.

     
    • Joseph Karr O'Connor 6:03 pm on February 15, 2013 Permalink | Log in to Reply

      Not all SR users navigate by ARIA routines, especially less experienced users or those who have not upgraded their SR. I believe a separate accessible version is the way to handle this.

    • Jacek Zadrożny 12:32 pm on February 16, 2013 Permalink | Log in to Reply

      I think that the best way is similar to putting widgets. Small form with name, priority and so on.

    • _Redd 3:07 pm on February 18, 2013 Permalink | Log in to Reply

      I am speaking out of ignorance here, so please accept my humiliation in advance if this idea has no possibility of working.

      It is possible to re-order pages in WordPress. We can do it by hierarchy, which involves a drop-down option, which as I understand it creates all kinds of problems for AT. But we can also re-order the pages order by simply typing in a number in a field. Is it possible to somehow exploit the code that changes the order of the pages, and apply it to re-ordering the items on a menu? We could \”focus\” the menu item in the same way that we could \”focus\” the page order.

      (Specifically, in the Page Attributes section, I\’m referring to the \”Order\” option)

      Am I making sense?

      • _Redd 3:30 pm on February 18, 2013 Permalink | Log in to Reply

        Small form with name, priority and so on

        Which, when I think about it, is what Jacek is saying, isn\’t it?

        Sorry, Jacek, realizations happen to me slowly……..I\’m having one of my Doh! moments…. 🙂

      • GrahamArmfield 5:42 pm on February 27, 2013 Permalink | Log in to Reply

        Have thought about this a bit more and done some investigation in how the Custom Menu items are stored etc.

        I think that the two key bits of hierarchical information that people need to manipulate for each item would be:

        The parent item for this item – could be none of course
        The menu order (which would only come into play against sibling menu items?)

        It’s a bit like setting hierarchy for pages in the old way – Who is my parent? What is my order number?

        So an accessible option would need to incorporate a dropdown and a text box for each item – alongside the other extra data stored – classes etc.

        • ceo 6:42 pm on February 27, 2013 Permalink | Log in to Reply

          You mean this, @grahamarmfield?

          With the use of custom menus, it’s basically a depreciated feature, but it’s still available as a setting within Page Attributes. (Those settings were how I had my navigation menu built in an older theme as it used the data for pages.)

          EDIT: Whoops. Helps if I write the HTML properly.

          • GrahamArmfield 6:54 pm on February 27, 2013 Permalink | Log in to Reply

            Yes, exactly that Cyndy. I still have a couple of sites that rely on wp_list_pages.

            I’ve been looking into the menu object and what gets stored about each menu item as I’ve been working on a plugin.

            It’s fairly easy to retrieve a list of items in a custom menu.

        • _Redd 6:53 pm on February 27, 2013 Permalink | Log in to Reply

          @GrahamArmfield, I’m not clear as to why a dropdown is needed (speaking as a very, very ignorant person here)

          Isn’t there some way of entering a number in a field, and then just set up an “order_by” function?

          Honestly, I’ve been thinking of hijacking one of the menu attributes in the menus screen, the field that says, “Title Attribute” and trying to convert it to a field by which users could enter numbers. From that point, maybe it could just be a matter of displaying the hijacked “Title Attribute” as a re-purposed field by which to enter a number, and then have an “order_by” ASC or DESC

          Am I making sense?

          I would ask if I’m crazy but I already know the answer to that one…..:-)

          • GrahamArmfield 6:56 pm on February 27, 2013 Permalink | Log in to Reply

            I might have misunderstood the menu order setting but I think we’d need users to specify a parent for a menu item as well as the order once they’d pull items across from the pages, posts etc boxes. On it’s own the menu order won’t do that – will it?

            • _Redd 6:57 pm on February 27, 2013 Permalink

              I don’t know….I’m pretty sure I’ve done it with at least a “no parent” setting, which I guess parent = 0, and re-ordered pages that way. No dropdown or reparenting involved. Let me check right now on one of my sites.

            • GrahamArmfield 6:59 pm on February 27, 2013 Permalink

              But if I want to set something as a parent for a menu item, how would I do that from the menu order alone. That doesn’t convey the hierarchy, that menu_parent_id does I think.

            • _Redd 7:00 pm on February 27, 2013 Permalink

              Just tried it, works without setting a parent. I’ll try and get a screenshot

            • _Redd 7:03 pm on February 27, 2013 Permalink

              Graham, I may be misunderstanding what you’re talking about, and I know that your knowledge of HTML far outweighs mine, so let me revisit.

              I consider the parent the menu itself….if we have a home menu, then that is the “parent” item–“home”. If we have a “dog” menu, then we have a “parent” item in “dog” Beyond that, I’m not seeing a need for any additional parents.

              I hope I’m making sense……

              Let me get a screen shot or two

            • _Redd 7:04 pm on February 27, 2013 Permalink

              Just tried it, works without setting a parent. I’ll try and get a screenshot

              And in this case, I specifically meant for pages…be right back

            • ceo 7:11 pm on February 27, 2013 Permalink

              Wouldn’t the parent specify if the menu item was “nested” under (i.e., creating a sub-menu)? At least, that’s how it works with the Page Attribute. I don’t think simply ordering the item would accomplish this, and currently the only way to do this now is via drag-and-drop.

            • GrahamArmfield 7:23 pm on February 27, 2013 Permalink

              _Redd, I was talking about influencing the hierarchy of items within a given menu – typically pages I would guess.

              If I add five pages to an empty menu – a, b, c, d, e their menu order might be:

              a 1
              b 2
              c 3
              d 4
              e 5

              But if I want pages b and c to be sub-pages of a, I think that their stored menu order would be identical. There isn’t enough to describe the hierarchy.

            • GrahamArmfield 7:26 pm on February 27, 2013 Permalink

              Cyndy (ceo) is right I believe, the hierarchy or nesting is defined by the menu_parent value.

            • _Redd 7:36 pm on February 27, 2013 Permalink

              @GrahamArmfield, @Cyndy, I unfortunately do not know enough about the subject at the moment.–that said, the code for reorganizing items exists in the page functions. We should be able to hijack that code.

              Here’s a sample of what I am trying to describe link to screenshots showing pages re-ordered non-hierarchal

              No drag-and-drop is needed to re-order the pages.

              Can’t we exploit that code somehow?

            • _Redd 7:37 pm on February 27, 2013 Permalink

            • ceo 7:47 pm on February 27, 2013 Permalink

              @reddhound – but the ordering itself is not the only option within the menu screen. Nesting/sub-menus also need to be accounted for, thus the “parent” suggestion. See: http://guidingdolly.com/nested-menu.png

              This is what I meant when I was referencing the drag-and-drop above.

            • _Redd 7:49 pm on February 27, 2013 Permalink

              @Cyndy @ Graham you have given much to chew on, and my head is spinning. I’ll put aside for now, keeping your comments in mind, and will certainly revisit.

              Thank you BOTH, and will “talk” to you soon!

              Take care

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

      Did you see ticket 23607?

      this awesome ticket 23607 is referencing a task to Give the menus page an accessibility mode (like widgets), based on ticket 14045

      This is Terrific!!

  • esmi 1:41 pm on February 14, 2013 Permalink
    Tags: ,   

    Post Revision Timestamps 

    Following a suggestion from @Ryan McCue about making timestamps in post revisions human readable, I’ve set up a test case that uses both human readable and W3C recommended timestamp formats.

    All feedback and comments here, please.

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

      1. Is it possible to differentiate between the original text, what has been deleted and what has been added?

      Yes very clear

      2. Are any of the timestamps perceivable?

      I don’t see time stamps on Firefox 10.0.2 , Chrome Version 24.0.1312.57 m IE9 , at least, not rendered as text on the page. Did you mean that the time stamps should be visible in code? I can view code and see time stamps

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

        The visual presentation is being controlled by Twenty Twelve and it is nice to see that it does a good job of it. But what about those who cannot see the visualisation? In theory, the ins and del tags should be rendered appropriately in screen reading software but I don’t know how (or even if) they render the attached timestamps. If they do, then the format of that timestamp may be critical. The sooner we can let the UI team know what format(s) they can (and can’t) use, the better.

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

          Interesting. Hopefully, we’ll hear from some of our experienced screen reader users soon; in the meantime, I may just dig up the iPad and try to see what Voiceover does with that. …..it may have to wait until this weekend, but I think this is most certainly a worthwhile pursuit!

    • heidi 3:52 pm on February 14, 2013 Permalink | Log in to Reply

      in using JAWS screen reader with I.E. 8 and Firefox 18.0.2 two paragraphs are read but there is no indication of any revisions or timestamp present.

      • tady 4:52 pm on February 14, 2013 Permalink | Log in to Reply

        That’s very interesting Heidi. Can you tell us what version of JAWS you are using? I was under the impression that it should be able to support.

    • tady 4:53 pm on February 14, 2013 Permalink | Log in to Reply

      That’s great Esmi, it’s great to see it in context. Really looks like a great addition. Be interesting now to hear the feedback from people using SRs now, like Heidi here.

    • Heidi 9:05 pm on February 14, 2013 Permalink | Log in to Reply

      I am using JAWS version 13.0.1006

    • Heidi 9:34 pm on February 14, 2013 Permalink | Log in to Reply

      regarding Esmi’s remark: In theory, the ins and del tags should be rendered appropriately in screen reading software but I don’t know how (or even if) they render the attached timestamps. If they do, then the format of that timestamp may be critical.
      … I would think appropriate rendering would be for them not to read in the actual post but should show up in the code so as to appear on the back end … in the code the time stamps are showing, they are nonsense in the first paragraph but read properly in the second. I hope I am understanding the purpose of this test correctly

    • Amanda 4:58 pm on February 15, 2013 Permalink | Log in to Reply

      I just looked at the test page, and using IE9, and Jaws for Windows 13, the timestamps are not visible, and there is no way to determine that text has been deleted. So to go through the test questions:

      • There is no way to tell whether text has been changed, deleted or added, ETC.
      • Timestamps are not perceivable unless looking at the underlying generated HTML.
      • The timestamps are not rendered in an understandable manner, at least on the front end, which is where I’m assuming you want them to show up.

      Amanda

    • esmi 5:02 pm on February 15, 2013 Permalink | Log in to Reply

      Thanks Amanda & Heidi. Based on the feedback thus far, it seems that JAWS doesn’t render these tags when used with your current configuration. Can I ask both of you whether you are using JAWS in a verbose mode?

    • Heidi 7:02 pm on February 15, 2013 Permalink | Log in to Reply

      I am using JAWS in beginner verbosity mode

  • 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,

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

    Post Revisons Update 

    I managed to drop into the Core IRC meeting yesterday and was told that the our recent feedback on the new concepts for post revisions was very helpful. New screenshot mockups have now been created to incorporate fixes for the issues that we raised.

    Coding on the new post revisions may begin shortly, so let’s keep an eye on the outstanding tickets and new developments. In the meantime, thank you to everyone who took part in the post revision discussion and let’s keep up the good work.

    We can make a difference! 🙂

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

      That latest mockup is AWESOME!!! It removes ambiguity in so many ways, and, it is easy to digest, cognitively speaking! Woo woo!

      • tady 4:55 pm on February 14, 2013 Permalink | Log in to Reply

        I know it’s just a mock up, but as a fully able person, I actually find the text behind the delete hard to read now. Will this render similar to the example you created above Esmi? If this is the case, then my point is moot and it’s just a symptom of the wireframing tool.

        • _Redd 6:15 pm on February 14, 2013 Permalink | Log in to Reply

          @tady, I sure understand why you find the text behind the delete hard to understand, but you may want to keep in mind that deleting whole paragraphs is not necessarily typical when editing documents. In one of my former jobs, I was basically a document editor, and I had to share those edits with others located at remote points of the globe. The edits would typically be by word or by sentence, not by whole paragraphs, and that strikeout feature (used in Word documents) came in extremely handy for finding edited areas fast.

        • _Redd 6:27 pm on February 14, 2013 Permalink | Log in to Reply

          @tady Although, that may bring up a point for consideration–is the intent to COMPARE versions (no need for deletion marks) or to REVISE versions (deletion marks are expected)–that may make a difference in how the text is emphasized.

          And again, thank you, thank you, thank you, for everything you are doing!

          • tady 8:11 pm on February 14, 2013 Permalink | Log in to Reply

            Yeah, I got this reply on my phone and found myself asking “Good point, what DO I actually mean?!?”

            I suppose for me, as a developer, I expect to see revisions for comparison. I would rarely expect the system to make decisions about which version I wish to chose without my input. Therefore, I suppose in that context, it makes more sense to me to have the content available for comparison WITHOUT the strike through. However, having said that, it is not always programmatically that one might be looking at this feature (I recently had to point out to a journalist who uses WordPress every day for their news site, how to find revisions. To say I was popular as a result would be an understatement!). In this instance, it would make more sense to see them in the context of their title (i.e. as a REVISION) and in that situation, the strikethrough makes perfect sense.

            On the whole, I like the strikethrough as an idea and I do believe, based on Esmi’s examples, it will still be legible. My comments were really, solely based on the wireframes which, having drawn them up myself in the past, I figure is just a factor of the wireframe implementation, than on real life representations of the same.

            Possibly still up for discussion a bit, as I haven’t really answered any questions proper here, but hopefully this gives a bit of clarity on my stance and the context of my original point.

    • esmi 5:12 pm on February 14, 2013 Permalink | Log in to Reply

      Will this render similar to the example you created above

      Yes — see the latest screenshots. I know what you mean but, as far as I am aware, strikethrough is the default treatment for the del tag in graphical browsers since about 1998. Not sure if we should mess around with that too much.

      • Joe Dolson 6:08 pm on February 14, 2013 Permalink | Log in to Reply

        There are some sneaky things that can be done with CSS to modify the apparent weight of strikethrough that can make it a little easier to read:

        del{
        position: relative;
        }

        del::after{
        content: ”;
        border-bottom: 1px solid red;
        position: absolute;
        left: 0;
        top: 50%;
        width: 100%;
        }

        I don’t know whether that’s a good idea, but it would be possible. As I understand it, IE and Firefox increase the weight of the line with the font-weight and size, and this would prevent that from obscuring the text.

        • _Redd 6:23 pm on February 14, 2013 Permalink | Log in to Reply

          @joe, (I want to call you AWESOME Joe for that plugin work you’re doing!!)

          Before pursuing that, let me try to reproduce a problem I had earlier with fancy text-I recall that when manipulating text with some fancy CSS, I found out that the text would not print!

          It was bizzare!

          I promise, I could not or would not make this stuff up. I’ll try and find my old records to see what I did to cause that to happen, but I don’t think it was anything more fancy than adding a border on the bottom to simulate a shadow. I was stunned to see that it caused text not to print.

        • tady 8:16 pm on February 14, 2013 Permalink | Log in to Reply

          Yeah, I’d avoid this on the basis of experience. I’ve never had much joy in replacing a typeface representation with a graphical equivalent. An example would be trying to make the underline on links as a dashed element as opposed to a solid line. It just never really works cross browser with the same stability as the actual (text-decoration:underline, etc) typeface formatting. There’s also the question that the difference or revision may not just be a whole paragraph, but could be a word or a phrase. Applying positioning to this element inline won’t always layout the best. I really can’t emphasise how much I’d shy away from this substitution.

          • Joe Dolson 11:09 pm on February 14, 2013 Permalink | Log in to Reply

            For clarity, it’s not the del element that’s being positioned, it’s a dynamically created element with an independent border being overlayed. Regardless, I don’t disagree: and it’s not certain it would really be any improvement, if the font in use is of average size and weight, anyhow. Although I suppose you could reduce the opacity, as well.

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