Web developer, writer, speaker. Co-founder of his company Algonquin Studios as well as evolt.org. Has co-written “Usability: The Site Speaks for Itself,” “Web Graphics for Non-Designers,” and “Web Professional's Handbook.”
Detail of the effect I wanted to re-create with a linear gradient — a gray column, a white narrow gutter, a black vertical line, and the rest as white.
I'm going to tell you up front that I don't have a fix for the issue I am raising, though there are bugs filed against it.
I wanted to create equal-height columns that don't use tables, piles of JavaScript, background images, or many of the other code-heavy techniques out there today. I just wanted a CSS-only option. I have played around with CSS gradients to define columns before, something it turns out was covered in 2010 at CSS Tricks, and I decided browser support had come along enough that I could make a prefix-free solution.
In the image above I show an example where I want a vertical line between two columns, along with a narrow gutter. This is pretty straightforward, though you're better off doing it by hand than using any of the gradient generators out there right now. Ultimately I needed a step that is one pixel wide (yes, I am using pixels for this example) that is also a solid color. Easy enough.
It turns out that Chrome, Firefox and Internet Explorer 11 just don't seem to dig making a one pixel gradient step. That's ok. I can work with that. What I wasn't prepared for was how Chrome (38 as of this writing, though this appeared in prior versions) opted to handle it.
At some window sizes, Chrome displays no step at all. At other window sizes, it's 5 pixels. Sometimes the widths of the other steps change as well. This means some Chrome users will see nothing, others will see something five times wider than I want. The animated GIF below shows what happens to the line (in red) as I scale the window width. I think you can agree that it can be a pretty jarring experience for users (part of me worries that this kind of rapid flashing on the whole page can also overwhelm some users).
Animated screen capture of the CodePen in Google Chrome 38 showing the stuttering width of the "columns" and the inability to handle a one pixel band/step.
skia discretizes the colors into 256 levels for (lots of) speed. hard-edged gradients like this (where there are two colors at the same color-stop) definitely show up this limitation. We can look at ways to increase precision, but there will be a real performance cost, so we have to decide how important this particular behavior is in practice.
Essentially the argument is that this is a performance trade-off. One that both Firefox and Internet Explorer seem more than capable of handling, which means I'm not buying this excuse a year and a half after it was offered. It just feels like a cop-out.
If you think that your work could benefit from having these bugs fixed, please go star them. Otherwise we may not use that awesome CSS feature, and by extension we're enabling the browser monoculture that is Chrome.
I posted a link to my pen and this post to the bugs, and in both cases I later got email bounce notifications ("The email account that you tried to reach is disabled."). The address srsrid...@chromium.org, the only CC on 281489 and one of two on 233879, is gone which makes me think nobody is listening on at least one of the bugs.
I've seen some movement on the Twitters (and the W3C HTML Working Group mailing list) over the last week or so suggesting that there was going to be some announcement, but this tweet from HTML5_Chewbacca pretty much gave it away:
I don't speak Wookie, but I think he's pretty confident that HTML5 would be wrapped up before November.
Of course, I was literally at lunch when the email came through on the mailing list, as well as the tweet from the W3C. But since this post is more of marker for me to reference, I'm not bothering with meat here. I will, however, link to other posts on the web.
There's also this explainer video for those who may not be quite sure just how web standards are a good thing:
Five years ago today Google's CEO made predictions about where the web would be in five years. He did not predict HTML5 was going to become a recommendation today. And you trust this guy with your searches? Anyway, snarkiness aside, I think W3C Memes captures it pretty well with this image:
On Saturday, November 15 I will be kicking off WordCamp Toronto with my talk "Selfish Accessibility." In case you haven't been following my blog, I use the talk to make the case that supporting accessibility best practices is actually in your best interests as a user. Or I can let the event description explain it for me:
We can all pretend that we’re helping others by making web sites accessible, but we are really making the web better for our future selves. Learn some fundamentals of web accessibility and how it can benefit you (whether future you from aging or you after something else limits your abilities). We’ll review simple testing techniques, basic features and enhancements, coming trends, and where to get help. This isn’t intended to be a deep dive into ARIA, but more of an overall primer for those who aren’t sure where to start nor how it helps them.
What will attendees learn from this presentation?
Recognize that they are all going to qualify as disabled users.
Recognize that non-disabled users benefit from accessibility affordances.
Perform simple accessibility testing.
Have reference material and resources to continue self-education.
Write code that uses ARIA properly.
Write basic HTML that isn’t a barrier to accessibility.
Apply these skills to any platform.
While I may start off the accessibility track on Saturday, there are talks all day Saturday and all day Sunday. It's a full plate of great content — some of which is from speakers I have seen before, so I know it will be good. Check out the schedule to see what's available.
Registration for the weekend is only $30, so you may want to register now to make sure you get a spot. Whether or not you can make it, you'll be able to follow tweets from attendees (and organizers) on Twitter with the hash tag #WCTO.
I just finished a webinar for the National Association of Government Web Professionals where I provided an overview of responsive design. I always struggle when I cannot see the audience, but as always my ego carries me through to the end. The slides are embedded here for any and all to see.
This is one of the images tweeted by the CDC. The text contrast is 4.53:1, so it barely passes for large text. At this scaled-down size, however, the question text would fail a contrast test for accessibility.
In the United States, the Centers for Disease Control (CDC) is (or at least is supposed to be) the first line of defense against public health threats like Ebola. It makes sense, then, that the CDC would use social media to assist its efforts to get useful information in front of as many people as possible.
The problem is that the CDC's efforts on Twitter have fallen prey to reliance on the image attachment. When Twitter proclaims that engagement goes up when images are used, and because tweets limited to 140 characters, it can be pretty compelling to use images to convey a lot more content than would otherwise fit — and it can be styled and better branded.
The CDC Emergency Preparedness and Response account started an Ebola fact campaign, framed as a Q&A series of information nuggets (which makes me think it's really an Ebola FAQ campaign, but I digress). Here is the text of these tweets so far (no images):
Don't think the White House is doing much better. While the tweets at least include URLs to get more information, the text within the image is not included in its same easily-digestible form, and the data contained in the image is scattered across a long-form article on the site.
Even if you're not the CDC, I think there is still a lesson to be learned here — putting all your tweet content into embedded images is a great way to exclude users. Thankfully the CDC can choose from one of three (four?) easy fixes.
Make Supporting Web Pages
The CDC can simply link to the content in the images as equally-short nuggets on its web site. Clear out the cruft of third-party "share" icons, remove the excessive footer, and generally pare the page down to the fastest load possible. To support these users, don't make them have to navigate to the nugget of content when landing on the page, make it the entire page.
Tweet Your Own Alternative Text
There has been a trend in the accessibility community on Twitter to include or describe images in their own tweets and sometimes in others' tweets.
Alternatively, look at a tool like Easy Chirp to embed the full text content within the tweet itself. It already has traction in the blind community, so those already familiar with it don't have to struggle through a learning curve.
Here's the same tweeted image as CDC's first Q&A tweet, but this time it has alternative text just one click/tap away (without losing the image for sighted users):
It looks like both CDCEMergency and CDCgov have each improved a tiny bit in their most recent tweets, insofar as the key point of the message in in the text of the tweet (even if there is still no full alternative text):
I intentionally didn't allow any of the images in the examples to embed. I think you should experience the tweets the way a blind user would (with the exception of the opening image with its low contrast). However, I also want to make sure the content is still available to readers. So I am helping the CDC here and including the text from each image above (also linked from each image above).
CDC Ebola Q&A:
Q: Can Ebola spread by coughing? By Sneezing?
A: If a person with Ebola coughs or sneezes on someone and saliva or mucus contacts that person's eyes, nose or mouth, disease may be spread.
http://cdc.gov/ebola
CDC Ebola Q&A:
Q: How long does the virus live outside of body? What effectively kills it outside of body?
A: Ebola on dried on [sic] surfaces such as doorknobs and countertops can survive for several hours; however, virus in body fluids (such as blood) can survive up to several days at room temperature. Ebola is killed with hospital grade disinfectants (such as household bleach).
http://cdc.gov/ebola
CDC Ebola Q&A:
Q: If Ebola isn't airborne, why do health workers wear protective gear?
A: CDC recommends Ebola healthcare workers wear protective gear due to the possibility of large amounts of blood, other body fluids, vomit, or feces present in the environment.
http://cdc.gov/ebola
CDC Ebola Q&A:
Q: Can I get Ebola from my dog or cat?
A: At this time, there have been no reports of dogs or cats becoming sick with Ebola or of being able to spread Ebola to people or animals. The chances of a dog or cat being exposed to Ebola virus in the United States is very low as they would have to come into contact with blood and body fluids of a symptomatic persion sick with Ebola.
http://cdc.gov/ebola
CDC Ebola Q&A:
Q: What is the incubation period for Ebola?
A: The incubation period, from exposure to when signs or symptoms appear, is to 2 to 21 days, but the average is 8 to 10 days.
http://cdc.gov/ebola
Facts about Ebola
When is someone able to spread the disease to others?
Ebola only spreads when people are sick. A patient must have symptoms to spread the disease to others. After 21 days, if an exposed person does not develop symptoms, they will not become sick with Ebola.
Get the facts on Ebola:
Ebola is not spread through: Casual contact, air, water, food in the United States.
WH.gov/Ebola-response
Get the facts on Ebola:
You can only get the Ebola virus through direct contact with: body fluids of a person who is sick with or has died from Ebola; objects contaminated with the virus; infected animals.
WH.gov/Ebola-response
In a departure from the other times I have given this talk, I gutted all the slides with code samples as well as the slides on testing (although I did keep them handy and use them for the individual Q&A afterward). Instead, I added a section showing example selfish user stories, some persona bits, and other references. Overall I think it was a great fit. I met the time limit and didn't seem to overwhelm the crowd with technical bits. I hope everyone attending got something from the talk, but based on a few conversations afterward I think I struck a chord with at least a handful.
There was no video from this talk, so you have to take my word for it that it went well. I was warned in advance that the crowd would be tough — they wouldn't laugh at my awful jokes (nor the good ones), wouldn't ask questions, and in general might be hard to read. That was wrong. The room was great and was easy to engage. I think it helps everyone was hoping to learn something new on a topic that many hadn't considered before.
Tweets
Even if you can't integrate accessibility into your UX design now, you should be working towards it @aardrian#uxsg#accessibleux
Breakfast bits on the first day of #uxsg. Tasty breakfast and tea snacks continued throughout.In Bryon Long’s #uxsg lean startup session, he identified being bald and dating as a type of problem.#uxsg In “think like entrepreneur” session, @trentmankelow asked each of us to draw ourself.We were also asked to add some fact unknown to the group. I mentioned my durian fascination.Cutting my #uxsg slides down to 75 after chats today. On a rooftop bar with various animal satay and a Generously Scarlet.The Donnie-Darko-style #uxsg Super Garang looking on after the end of the conference.
