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.”
I spent Saturday in the accessibility track (I missed one talk, sadly). There was some overlap on general themes, which I think was good. Overall, anyone who visited one talk still got a common baseline, while those who stayed for the day had the core accessibility information reinforced across speakers.
I was thrilled I got to present in the same track as Billy Gregory and Karl Groves, also known as The Viking and The Lumberjack. These guys know their stuff.
Often when I identify a valid technical (typically accessibility) issue with a site, tool, or library and get a response of just make a pull request, I am thrown into an apoplectic fit for which I have to apologize to my co-workers (or people at the random coffee shop or airport).
My Thesis (Rant)
I am not going to fix your arcane niche library/tool nor your single-use site that you'll dump in a few months. That isn't a good use of my time, and you learn nothing.
I bill for doing just that; it's how I earn a living. Like all of you, I have many things to do besides my day job, some of which are far more important to my community or personal well-being.
I speak at conferences and write for sites not just for free, but at a cost to me in most cases (nearly all cases), specifically to teach the skills that would allow you fix the issue on your own. I do this without targeting a specific language or platform except where it most directly impacts the user (typically HTML, CSS, and vanilla JavaScript).
I am trying to identify issues and arm you to fix them, both in this case and for the rest of your career.
Asking me to fix it (hey, just make a pull request) is a cop-out. It's short-arming your own technical growth.
Fix it yourself.
Learn how to do it.
Carry that skill forward to future projects, enriching both your users and your career.
Take some pride in your craftsmanship by learning how to address a valid problem.
Short-arming accessibility (the vast majority of my bug reports) is why we're inundated with inaccessible libraries and tools. It's always someone else's problem.
My Pedigree
I've been performing reviews, contributing to and building one of the first developer sites and lists, speaking, writing tutorials, articles & books and generally been offering my time and expertise for free or nearly free for almost twenty years.
If I tell you that your site doesn't print and you suggest I can give away my time to fix it, I'll note that I've already done so. In some cases I've spent more time educating for free than you spent building the entire project.
I've given back, and I continue to do so. In a way that will outlive your site or project.
Ideally, my talks and writing reach more people than one bug report. Hopefully they provide real-world context and examples for others to draw parallels to their own projects.
My Overreach
My mentor would always ask the same question when I whined that somebody wouldn't do something I wanted. He'd ask, What are you going to do about it? Karl Groves makes the same point, essentially, for open source projects:
When you bitch about an open source project, you're not solving anything, just making noise. Stop bitching. Start fixing.
Sometimes that applies, sometimes it doesn't. Karl is right in his response that two thousand word blog posts aren't even bug reports. I get that. I encourage you to read the entire Twitter thread; there are valid points on both sides, some which poke holes in my argument above (in specific cases) and some which bolster it.
When it comes to non-open-source projects or sites, it's a bit more difficult to just do something. I've spent more time trying to get Virgin America to fix its keyboard accessibility failure than if I had been granted access to the code to remove one line of CSS. In those scenarios I am stymied.
If you are a developer and find an issue as part of an open source project and have the time to fix it, do as Karl suggests above and fix it.
If you don't have the time nor inclination, help the developer with a detailed bug report. You don't have to use the bug reporting tool, you just need to get it some attention.
If you're a developer and you've had a valid issue identified, then don't expect the person reporting the issue to fix it. It is fine to ask for help if you don't understand the issue.
Asking the person who reported it to learn your bug tracking system is a bit much. Accept the feedback as offered, even if by Tweet (where you may be most accessible).
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
