Post Revisions in 3.6
The Post Revisions are currently being overhauled for WordPress 3.6. The team responsible are at the concept stage & they’ve asked asked us to provide feedback now on their current mock-ups.
I have already raised the point elsewhere that perhaps a red/green combination isn’t the best of choices but I do think that the potential barriers here could be greatly mitigated if one of the mock-ups with strike-through (currently the favoured approach) was chosen. The screenshot below shows how these screens might be viewed by someone with the most common forum of colour blindness (protanopia).
Seems to me that the markup used could also greatly enhance accessibility here — with proper use of both the <ins> and <del> HTML tags.
Any other thoughts?
ceo 11:49 am on February 8, 2013 Permalink
I’m completely colorblind so the color differences are basically lost on me. Highlighting does draw attention to the different text, but does also make it harder to read in some cases. I like the idea of the strikethrough text.
esmi 12:52 pm on February 8, 2013 Permalink
When I checked the foreground/background color contrast on the last round of mockups, the red just failed but the green was failing badly. We definitely need to ensure that the contrast remains at least 4.5:1
ceo 6:31 pm on February 8, 2013 Permalink
@Redd said my thoughts below – the background color changes are MUCH better than changing the text itself, but I like the idea of that plus the strikethrough personally.
Joseph Karr O'Connor 11:51 am on February 8, 2013 Permalink
Thanks for applying the protanopia filter. Is there a built example where we could use AT or accessibility checking routines? I will have to experiment with strike-through and SR.
esmi 12:56 pm on February 8, 2013 Permalink
This is still at the mock-up stage, so no. When I get a chance, I do intend to start looking at setting up an install that uses SVN and where I can apply specific patches for testing. Access to this install will be available on request. But right now, I’ve not even had a chance to locate the documentation on setting up this kind of install yet. — let alone read it.
Redd 12:51 pm on February 8, 2013 Permalink
The use of color as a way of passing information about the status of the text is definitely a problem for many of my students and the general population, especially when the colors are so close in “value” to each other.
That said, when I made further explorations of the proposed interface here:
http://make.wordpress.org/core/2013/02/05/revision-update-25/#comment-7943
I found the text’s background is highlighted—and a huge improvement. That background highlight actually improves readability/comprehension, because it facilitates cognition, and it does so rapidly—visual areas are organized into great groups by placing a background color to the paragraphs. It’s similar to the “outline” function in a:focus…..serves the same purpose.
I personally support the text background highlighting (NOT highlighting the text, highlighting the background)—WITHOUT the use of color as “code” for what is happening.
It’s really awesome how Eric and the 3.6 Post revisions team shared this for comment. Super great!
esmi 12:59 pm on February 8, 2013 Permalink
So what about a highlight background plus strike-throughs and
<ins>and<del>HTML tags? With checks for contrast levels?karmatosed 12:59 pm on February 8, 2013 Permalink
I’m one of those working on the revisions team and would like to thank you all for your feedback on this. My plan is to listen and work on a revised mockup based on suggestions (or few as the suggestions come). From there we can look to have it made into something code based when tests can be run on the patches.
Thank you all though for your fast responses on this and looking a this – it’s really cool.
Redd 1:06 pm on February 8, 2013 Permalink
Thank you karmatosed, for being involved! It IS cool!
Redd 1:05 pm on February 8, 2013 Permalink
I personally am a little worried about the strike-through, although I feel they are an improvement. In a sense, strike-thoughs add “details” to the text, and that is more “stuff” one has to sort through, cognitively, when looking at a page.
That said, I would still support a strike-through because because it outlines in no uncertain terms what is intended to happen to that text.
Maybe, a case where the text has strike-though and a background highlight to facilitate both cognition (outlining a paragraph via a background highlight) and signaling intent (through the strike-through). The fact that a light-colored background “softens” the visual distinction of the text around it might also soften some of the “messiness” of the added details that the strike-through brings, making it all a little softer on the eyes.
In other words, maybe we can have our cake and eat it too?
Redd 1:11 pm on February 8, 2013 Permalink
Doh! Sorry esmi….you said strike-throughs PLUS highlights…….
Definitely YES!
I better get more coffee! And a little more sleep!
tady 2:55 pm on February 8, 2013 Permalink
FYI,
<ins> and <del>tags can also use the datetime attribute, which would certainly also be helpful for highlighting date differences between revisions.tady 2:56 pm on February 8, 2013 Permalink
Dammit, formatted my post instead of showing the tags. What I said above is that the <ins> and <del> tags can use the datetime attribute. (Crosses fingers)
Redd 3:30 pm on February 8, 2013 Permalink
To esmi and tady, absolutely, positively YES in regards to the use of the
<ins> and <del>tags….if those tags are able to use datetime attributes in addition to being able to to strengthen the visual presentation of the text, then all the better.I was not aware that the tags could use the datetime attribute! I’m going to try to incorporate them in my scratch site when I have a chance, to see what that’s all about!
Redd 3:31 pm on February 8, 2013 Permalink
Well! I did the same thing, tady! Left the tags open……..so I “struck out” ! Heh…
tady 4:29 pm on February 8, 2013 Permalink
Yeah, easily done!
Here’s the W3C spec on the topic.
http://www.w3.org/TR/2011/WD-html5-20110525/edits.html#attributes-common-to-ins-and-del-elements
tady 4:32 pm on February 8, 2013 Permalink
Actually, it also supports the “cite” attribute. I missed that. That also could be a helpful addition. I don’t quite know what you’d cite (author name?) but it might be beneficial for some features.
Redd 8:03 pm on February 8, 2013 Permalink
tady, the link you provided was AWESOME. I’m still reading it
!
I guess I have a couple of concerns about using the tags now….I’m not saying “no”, I’m just saying I have some second thoughts….
the first, is that although I try to use HTML5 whenever and wherever possible, I’m not sure the standards have “gelled” sufficiently for WordPress to rely on it. There’s a honking big red warning to that effect on the pages covering those tags
The second is that apparently, The content models of the ol and ul elements do not allow ins and del elements as children (See section 4.7.5 Edits and lists)
I think whatever is chosen, the visual feedback needs to be consistent through the editing process. I worry users would have expectations that the lists would be treated the same way as the other content when revising. So, if HTML5 ins and del tags aren’t supported in lists, I would be a little more hesitant to implement it.
I’m just thinking out loud right now……What are your thoughts?
Redd 8:22 pm on February 8, 2013 Permalink
One other thing…..I’m not sure, but I think most screen-readers are not set up for HTML5 tags. If I understand the situation correctly, screen readers largely incorporate HTML4 technology, so maybe we shouldn’t be considering HTML5 types of tags for critical visual information…..or if we do, maybe we should ensure some sort of coding to work in concert with the tags…..but oh my gosh, that’s a LOT of follow-up work. And, for that reason, would be prone to errors from being missed.
esmi 8:45 pm on February 8, 2013 Permalink
<ins>and<del>have been part of the HTML specification since… um… 3.2 at leastRedd 9:20 pm on February 8, 2013 Permalink
ins>and del have been part of the HTML specification since… um… 3.2 at least
…oh…I am burying my head in the ground in embarrassment…….looks like I STILL need more coffee! Thanks esmi!
esmi 9:24 pm on February 8, 2013 Permalink
No problem. They’ve always been very under-used tags, so people just forget about them.
tady 10:34 pm on February 8, 2013 Permalink
Yeah, it happens. I had to explain the marquee tag (and why NOT TO USE IT EVER) to someone lately. It’s like the
andtags. A lot of people don’t know about some of the older tags because they’re used so irregularly. Not to worry Redd, you learn something new every day! I think the datetime element of them could be new. I don’t think any of the 3.2 or 4 spec HTML tags supported datetime, so that may be a HTML5 attribute, but eitherway, the datetime attribute on it’s own is supported by the majority of screen readers currently. What is worth noting is that they don’t all appear to handle it the same way. The default recommendation is that the datetime attribute holds the date/time in ISO format (that’s the long one, without looking it up, that looks something like 2013-02-08-23-30-00+00ZT). There’s nothing that says this attribute has to be specifically included this way, just that’s the development recommendation (I assume because it’s easier handled from a machine code perspective). Screen readers have funny ways of interpreting this, so it might be worth while if, as in this example, the datetime attribute is being used SOLELY for accessiblity reasons, to include a more “real” format (e.g. Friday, 23rd Feb 2013 at 11:30pm UTC). I’m not sure how this will fly with the devs, but worth mentioning overall I suspect.Anyway, glad to have been some help. Like I said before, intend on contributing more than I have been up to now.
tady 10:42 pm on February 8, 2013 Permalink
Also @Redd, with regard to HTML5 not being supported right now, this is mostly correct, but the ideal method of coding HTML5 is to include ARIA roles and attributes. This is not really being supported by the large majority of developers in reality at the moment, but the more this is incorporated into well known CMS systems (like WordPress) the greater adoption rates will be. I personally have no problem with using HTML5 templates from a theming perspective (mostly using a modified version of Elliot Jay Stocks “Starkers” theme), though I can appreciate the reservations from a backend perspective. It may also be a bit late in the game for 3.6 to include ARIA roles (this also puts great onus on plugin developers), but certainly worth considering. Not saying you’re wrong Redd, but on the basis of what the HTML5 WG are aiming to do, ARIA is front and centre. Jeremy Keith, Bruce Lawson and many others are firmly pushing the accessible element of HTML5. I fear it is the community who use it, as opposed to those who define it, will affect how accessible it is overall.
But hasn’t this always been the way!?
esmi 11:17 pm on February 8, 2013 Permalink
+100
It’s not our place to support the assistive technology (AT) out there. It’s our job to design pages the “right way” — according to the current specs & guidelines– and let the AT software developers do their own thing. We don’t design for specific browsers anymore, so we also shouldn’t support specific AT.
The only thing I would say about ARIA roles & attributes at the present time is that we shouldn’t rely too heavily upon them yet. Progressive enhancement and graceful degradation is always a good rule to develop by.
Ryan McCue 9:45 pm on February 13, 2013 Permalink
As in in-between, what about an RFC 2822 date? That looks like “Thu, 21 Dec 2000 16:01:07 +0200″ which is human readable (maybe harder for international users) but still machine parsable.
esmi 12:33 pm on February 14, 2013 Permalink
As long as the format is machine readable and can be parsed by screen reader software, I don’t think the actual format of the date matters. I’ll try to set up a very simple comparison test to get some real feedback on this.
esmi 1:36 pm on February 14, 2013 Permalink
Actually it looks like an RFC 2822 date format doesn’t comply with the HTML5 draft specification but I could be wrong. Plus, it is only a draft specification.
Nevertheless, I’ve set up a test case. Now to wrangle some feedback…
tady 1:15 pm on February 9, 2013 Permalink
Of course, that’s very true Esmi. Personally I’m all in favour of including ARIA roles in my own work as I feel it’s better to have something than nothing. While HTML5 is still settling, my preference is to offer something. I don’t actually know how helpful it is, but I figure it must be better than saying “I’ll just wait and see!”
Anyway, great discussion, looking forward to seeing the outcome.
Redd 1:01 pm on February 11, 2013 Permalink
Well, that statement put it in perspective for me. Thank you both, esmi, and tady, for the feedback. It actually helps provide direction for what I’m doing here at “home” so to speak. With that, let’s move forward–with modern tags!
John Saddington 2:07 pm on February 9, 2013 Permalink
Completely random resource: http://speckyboy.com/2013/02/04/myths-about-how-blind-people-use-the-internet/
Neat.
Redd 1:03 pm on February 11, 2013 Permalink
Not only “Neat”, but another awesome article I’m going to pass around at work. Keep ‘em coming!
The WordPress Weekend Roundup - WP Daily 2:16 pm on February 9, 2013 Permalink
[...] 3. Post Revisions in 3.6 [...]
WordPress › Accessibility Group Update: 13 Feb 2013 « Make.WordPress.Org Updates 3:07 pm on February 14, 2013 Permalink
[...] out a review of the new Post Revisions concept mockups at the request of the UI [...]