Tuesday, July 15, 2014

CSS Summit 2014 Slides: Making Your Site Printable

CSS Summit

This afternoon I awkwardly stumbled through my talk for CSS Summit, Making Your Site Printable. I can tell you that speaking to a screen instead of to a room full of people is a whole different experience than I was expecting. Fortunately for you I do not have an audio/video recording. I do however, have all the slides.


Making Your Site Printable: CSS Summit 2014 from Adrian Roselli


Links to resources referenced in the slides (in the order they appear):

Ticket Giveaway

I'd like to note that thanks to the generosity of CSS Summit, I was provided with two tickets to today's talks that I could give away as I saw fit. I opted to offer them to two deserving young women from the Buffalo chapter of Girl Develop It (neither heckled me):

The Twitters

Finally, one of the novel things about an online conference is that attendees seem to be more active on Twitter. I got feedback and questions, and even fielded a few sub-tweets (I happen to know the print styles aren't glamorous, but most of the fundamentals aren't). I've collected the tweets in a Storify, which I have embedded here:

Update: July 21, 2014

Based on the activity from these two tweets alone, I am really hopeful that web developers are starting to see that print styles have value and belong in a responsive workflow. Only time will tell. The tweets:

Friday, July 11, 2014

Patents versus Accessibility — Again

I've ranted about frivolous patents more than once here. Others far closer to the issue do it daily, so my voice is but a drop in the ocean (and yet nothing happens).

This time it's a little different, and yet familiar (read my April post Patents versus Accessibility). Thanks to a tweet from WebAxe, I found out that somebody has patented (granted June 26, 2014) a tool that automatically makes a web site accessible. I find this a preposterous claim (at best), but here's the abstract from the patent:

A method for an accessibility solution provided as a software. The method includes approving or implementing by a website owner of a code into his website and receiving web format by a user device by “scraping” the data from the website pages or by other means of using client side plugin, server side plugin, browser or 3rd party server side or mobile app. The method also includes analyzing the data over the user device or on the server side and clicking a button by the end-user and the original code and the content and code that were collected from the website are rewritten which can also be done automatically as a suggestion to the end user, and the end-user sees or can use a new format according to the updated standard.

Unlike so many frivolous patents that are nothing more than an idea, this patent has some compelling claims. Unfortunately, the likelihood that all those claims can be realized seems pretty small.

Why I Am Wary

Just as anyone who practices accessibility understands that there is no automatic tool that can completely and truly evaluate a site's accessibility, there is also no tool that can automatically make a site accessible. To quote Jared Smith of WebAIM fame:

Accessibility is a continuum. It is based on the user experience. It cannot simply be defined as pass/fail or accessible/inaccessible.

While I don't want to attack what may very well be the well-intentioned best efforts of a dedicated person or team to improve the nature of accessibility on the web, I also have too many conversations with clients who are happy to accept a one-click solution at face value, unaware of the risks. More than anything, this post will serve as a quick reference for the inevitable conversation I'll have with a client or prospect about relying on a tool like this (or perhaps this tool in particular).

I am interested in how this tool can evaluate the value of alt text on images, verify whether an article or section is the correct sectioning element, make sure that placeholder text is not a barrier, understand when a button should be used, and so on. And then fix all these by re-writing HTML, JavaScript and CSS and not introduce more issues. These are just a tiny, miniscule slice of the kinds of decisions that require a person who understands the context in order to be successful.

The Patent Holder's Qualification

The evidence doesn't bear out that this tool can do what it advertises. The company that makes it, which promotes its accessibility services, has many issues on its own site. Which begs the question, did the company use its own tool and get such awful results, or does the company not see enough value in it to use it?

I wasn't the first to tear into the site. Folks on Twitter independently identified issues with color contrast, keyboard navigation (ok, that was me), image alt text, use of a carousel, a blank accessibility statement, incorrect ARIA role use, and misspelled ARIA attributes. All this feedback was unprompted.

To be fair, the tool may not exist yet. The patent was only just approved, though it was filed over two years ago. While I don't want to name and shame, there really is no way to make my point about the proposed tool without doing so.

The Patent Holder's Possible Example

Looking to the site of the registrant of the patent (I also made a Wayback permalink) I see an "Accessibility" box floating on its home page which may provide insight into how this patent might be applied. This "Accessibility" box allows some rudimentary control over the content. For example you can scale the text up or down, something I first built into sites about 15 years ago. You can change the text to white on black or black on white (yes, I also did that about 15 years ago). Oddly, you can convert the page to grayscale, removing all color information (it's not obvious how to turn that off, so it's still gray for me). You can toggle "alternate navigation," which just puts a big box around items that have keyboard focus (the site benefits since it wrongly uses outline:none). There is an option called "Speed control" which may adjust the rate at which its carousel/slider changes. There is an option to "Block blinking," though its affect was not immediately apparent to me.

I'm not sure that the patent would withstand scrutiny from someone who has worked in web accessibility. Some of the ideas outline, while not implemented in the tool on its own site, seem to lean on existing technologies that themselves are subsumed within patents. For example, one of the figures in the patent shows how optical character recognition (OCR) can be used to convert the text in an image into text that can be passed along to the user (figures 7a and 7b).

The Takeaway

As always with what feel like frivolous patents, I fear that they can be used to block truly useful and innovative solutions from coming to market. In this case, I worry that the already poor state of accessibility on the web could be stifled if the patent owners try to exercise any claims against those of us who've been doing accessibility work for years.

Tuesday, July 8, 2014

Changing YouTube Playback Speed

This post originally appeared on the Algonquin Studios blog.

YouTube gives users the option to modify the playback speed of some videos. This is particularly useful in the case of videos that you are obligated to watch (training videos, terrible fan videos, the occasional conference talk, etc.) and want to get through quickly. You have the option to speed a video to one-and-a-half times normal speed and double normal speed. You can also slow a video to half speed or quarter speed, which can be handy when trying to draw out a training-over-lunch session.

In order to make a go of this, you’ll need to use the YouTube HTML5 player, which you can activate at http://www.youtube.com/html5 while logged into your Google account. If you worry about browser support (for both the HTML5 video element or the various codecs), the YouTube page will show you what your browser supports. In general, if you are using a current version of your favorite browser then you should be fine.

The opening image shows where the option lives. Sadly, that awesome video of Morrissey and George Michael doing film reviews has been pulled, so instead you can try it out on this video of Hitchcock’s The Lady Vanishes (I reference it in slide 58 of my Selfish Accessibility talk). The video also has closed captions and an audio description so it’s a great example of the accessibility features available for YouTube.

When at a video, click the gear icon at the bottom right and look for the Speed menu. If the video allows you to change its playback speed, it will be there with available options. This will only apply to the selected video. If you know of a setting to have it apply to all videos, please let me know.

If you still aren’t sure where this can handy, just try listening to Thundercats dialogue (particularly Panthro) at normal speed and then again at 1.5× normal speed. To me the difference is dramatic.

Saturday, July 5, 2014

Speaking at CSS Summit

CSS Summit

In just under two weeks the 6th annual online, live CSS and SASS conference, CSS Summit, will be underway and I have been asked to speak on print styles. You don't have to deal with airports, hotels, taxis, or strangers. Heck, you don't even need to leave your desk. The event description:

Environments for Humans brings together some of the Web's most notable experts in [CSS] and [SASS] for an all-new, three-day online conference, the CSS Summit 2014! Bring the experts to your desktop July 15-July 17, 2014 from 9AM to 4PM (CT).

I'll be speaking on Tuesday, July 15 at 11am CT (10am ET). The abstract for my talk should sound familiar to those who have heard me rant about print in the past:

The push for responsive web design has helped web developers consider how the sites they develop can adapt to different devices, including sizes, screen resolutions, and even contexts.

It should now be easier than ever to respond to a format that has existed since the start of the web — print.

I'll walk through the process for making your responsive sites respond to the format we most often forget and show you how to use Google Analytics to track what pages are printed from your site.

The rest of the speaker lineup is Estelle Weyl, Jing Jin, Luis Rodriguez, Matt Carver, Jason Pamental, Rachel Andrew, Ana Tudor, Dave Arel, Russ Weakley, Rachel Nabors, Justine Jordan, Chris Eppstein, Patrick Fulton, Ben Callahan, Tab Atkins, Roy Tomeij, and Sam Richard

Whatever you do, don't pay full price. You can get 20% off by using the discount code 20ADRIAN. So go buy some tickets now and then listen to me rant. Go ahead. Really, go on, buy a ticket.

Monday, June 30, 2014

Printing from Mobile Has Improved

With more and more people relying on a mobile device as their primary computing platform, it stands to reason that more and more mobile users may want to print web page content — whether directly to a printer or as a PDF for later use (or display as in the case of scannable bar/QR codes).


The state of print style support on mobile browsers has been abysmal for some time. At my talks on making sites printable I even demonstrated that by showing support in the latest and greatest (based on your platform preference) at the time (Samsung Galaxy S4 using the default Android browser). If you look at the slides (slide 50 from Stir Trek and slide 51 from WordCamp Buffalo) you'll see that the output was pretty much just the mobile layout centered in a sheet of paper, despite well-defined print styles.

Part 1 of 3, screen shot of printed output in default Android browser from May 2013. Part 2 of 3, screen shot of printed output in default Android browser from May 2013. Part 3 of 3, screen shot of printed output in default Android browser from May 2013.
Screen shots of printed output from a Samsung Galaxy S4 using the default Android browser, circa May 2013 (I forget which Android release this was). I didn't output to PDF because I couldn't at the time.


Fast forward and support for print styles in mobile browsers has improved. At least for Android.

My tests on an iPad were futile, as Safari and Opera Coast both want to print to a printer (which I don't have at home) and not to a PDF. I tried to print to Google Cloud Print from Chrome on the iPad and got 404 errors. Opera Mini just doesn't seem to offer the option. Anyone with an iDevice who would like to chip in, I used the Algonquin Studios jobs page for my tests, as it typically fits on one sheet.

On Android I had better luck. The default Android browser, Chrome and Firefox all allowed me to print. None of Yandex, Opera, Opera Beta, Opera Classic nor Opera Mini offered a print option. Screen shots of where you can find the print option in these three browsers:

Android browser print dialog. Chrome print dialog. Firefox print dialog.
Screen shots of print dialogs from default Android browser (Mozilla/5.0 (Linux; Android 4.4.2; en-us; SAMSUNG SPH-L720 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/1.5 Chrome/28.0.1500.94 Mobile Safari/537.36), Chrome (Mozilla/5.0 (Linux; Android 4.4.2; SPH-L720 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.141 Mobile Safari/537.36), and Firefox (Mozilla/5.0 (Android; Mobile; rv:30.0) Gecko/30.0 Firefox/30.0).

Unlike last year's tests, the print output of each of these browsers shows that they are using the site's print styles. Which means they are truly honoring responsive design by following the appropriate media query in the appropriate context. Examples of the output:

Screen shot of Android browser print output as PDF. Screen shot of Chrome print output as PDF. Screen shot of Firefox print output as PDF.
Screen shots of the PDF files from each of the three browsers (left to right, Android browser, Chrome, Firefox). Select an image to see the full PDF, but note that the Android browser (the first one) is a 14.7MB PDF while the others are less than 60kb.

Chrome for Android

Chrome did a great job of rendering all of the elements as I expect, namely similarly to how Chrome does on my Windows machine. By default it disables background colors, which is good for me since I have two errant declarations I did not clear. It also rendered the QR code which is only generated when the user prints the page (or performs a print preview). (I have a tutorial on how you can auto-generate QR codes at print-time should that feature interest you.)

Android Browser

The Android browser behaved a bit differently than Chrome. While it also ignored background colors and also pulled down the QR code, it didn't use the custom fonts. It also greatly reduced the margin at the top of the page. Most oddly of all is that it rendered the PDF as a bitmap. A 14.7MB bitmap. Whereas in the Chrome PDF you can zoom in to see crisp edges on the text and logos (SVG), the Android browser PDF shows the constituent pixels of every otherwise vector item.

Firefox for Android

Firefox honored the background colors (oops) and the typefaces. It failed to render the QR code. Firefox also scaled the text larger than Chrome and larger than Firefox on my Windows machine. Most interestingly of all, however, was the paper size. Unlike Chrome and Android browser (8.5 × 11 inches), the paper size on Firefox's PDF is 6.67 × 11.11 inches.

Other Platforms

As I noted above, I couldn't get print to work on my iPad. I also went to the Apple store to try it, but none of the devices that I checked were either connected to a printer or could print to PDF. I don't have a Windows Phone, though I also went to the Microsoft Store and still had no luck. I don't have immediate access to a BlackBerry of any kind. If you have a device and/or browser combo I did not test, feel free to comment below and let me know what you saw.

What to Do

(Continue to) make print styles. So far it looks like they will work on current mobile browsers that allow printing or that export to PDF.


If you want to learn how print media queries can be useful to you, check out any of the following links (which themselves may contain many more links).

Update: July 1, 2014

Kimberly Blessing was kind enough to test on Windows Phone, only to find that Blogger wouldn't let her comment. Her salient tweets to me follow:

November was kind enough to test on an iOS device and saw the same output as I got from Android. That's two platforms covered, which is good news in general.

Wednesday, June 18, 2014

Keep the Focus Outline

Animated GIF screen capture of Virgin America site.
This animated GIF is a screen capture of cycling through every interactive element (mostly links) on the page using just the tab key. You'll note that in all but one case, the only indication of any change is in the lower left in the browser's status bar where it shows the URL of the destination link. The URLs ending in a "#" are the booking options.

Today's rant is inspired by all the gushing over Virgin America's new web site — just because it's responsive.

To be fair to Virgin America, making its site responsive is a huge win for users whose primary method of booking is via a smartphone or tablet (or, god forbid, phablet or tablone). Its new site, however, is a huge step backward for users who rely on the keyboard as their primary method of interaction.

Virgin America's CSS has a style to identify anchors with focus (yes, there are other elements that should get focus, but I am looking at just the most basic support): a:focus {outline: thin dotted;}

What's so frustrating is that the useful style is then overridden with this harmful declaration: a:focus {outline: none;} This override greatly decreases the usability and accessibility of the site. Unfortunately, this practice is still common on many more sites across the web.

As a web developer, one of the simplest accessibility tests you can do is unplug your mouse. Two quick things to review as part of that: Can you interact with all controls with only the keyboard? Can you tell which item has focus?

Even if you aren't motivated to run that simple test from an overriding sense of being nice to your users, there's a legal concern here. As I wrote last week, the U.S. Department of Justice held H&R block accountable to Web Content Accessibility Guidelines 2.0 Level A and AA Success Criteria. That means there is case law for making your consumer-facing site comply or face penalties.

By excluding focus styles, Virgin America is running afoul of one of the AA Requirement 2.4.7:

2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)

In short, if your site doesn't make interaction elements obvious when accessed via keyboard, not only are you hurting users, you're opening yourself up to litigation.

Further Reading

Again, this isn't a new issue. It even has its own mini-site at OutlineNone.com, which offers these handy links:

To add another, this article, When Do Elements Take the Focus?, might be handy to understand just when you can expect to see :focus styles get applied by a browser.


In March I wrote about how Google removed underlines from search result links. My concern there was that web developers might follow suit. Between removing keyboard focus indicators and underlines from links, I am amazed that developers do so much to make the core interaction element of the web essentially hidden to so many users. I am reproducing the list of related links here as they are relevant to the overall issue of keeping links usable:

My Efforts to Reach Virgin America (so far)

I may have contacted Virgin America on Twitter once. Or Twice. Or three times. Perhaps even a fourth time. And filed a bug with WebCompat.com. And left a comment at Wired's article. I've embedded the tweets below so you an retweet if you are as whiny as I.

Update: June 27, 2014

On December 12, 2013 a rule became effective from the U.S. Department of Transportation (DOT) titled Nondiscrimination on the Basis of Disability in Air Travel: Accessibility of Web Sites and Automated Kiosks at U.S. Airports. That links points to the following section on accessibility:

Finally, we proposed a tiered implementation approach in which the WCAG 2.0 standard at Level A and AA would apply to (1) a new or completely redesigned primary Web site brought online 180 or more days after the effective date of the final rule; […]

As keyboard accessibility is one of the requirements of WCAG AA compliance, Virgin America's new site does not honor this rule. However, if the Virgin site officially launched before June 10, 2014, then it squeaks by on a date technicality.

More information on the implications of the law are in the post New accessibility rules coming to airline websites. Are you ready?

Update: July 21

It took just over a month, but Virgin America responded to me:

I don't see any reason to follow and/or direct message to share more information. I have this blog post, which I've linked repeatedly. I think that's plenty. I responded and asked if or when the issue would be fixed, but I've been met with silence. Perhaps in another month I'll hear more.

In the meantime, given the amount of action the below tweet of mine has gotten, I know I am not alone in thinking that disabling the focus outline is generally a bad idea:

Sunday, June 15, 2014

Verizon Using Disabilities to Fight Net Neutrality

On Friday, Mother Jones reported that it has three sources saying that Verizon lobbyists are making a case on Capitol Hill that net neutrality harms those with disabilities. From Mother Jones:

Three Hill sources tell Mother Jones that Verizon lobbyists have cited the needs of blind, deaf, and disabled people to try to convince congressional staffers and their bosses to get on board with the fast lane idea. But groups representing disabled Americans, including the National Association of the Deaf, the National Federation of the Blind, and the American Association of People with Disabilities are not advocating for this plan. Mark Perriello, the president and CEO of the AAPD, says that this is the "first time" he has heard "these specific talking points."

In the absence of seeing the language Verizon is using, I can only go on what Mother Jones reported (other news outlets covering this are linking back to Mother Jones). Given the amount of cash ISPs like Verizon are lobbying to kill net neutrality ($19 million in the first quarter of 2014 alone), I don't consider this report to be far-fetched. Certainly Verizon is unlikely to make this argument in the open — there will be a backlash when no proof is offered and disability rights groups shoot it down (as has been happening just on these rumors).

It seems to me it is in the best interest of net neutrality to react as if this report is true. Further, it seems like a good idea to make it clear disabilities cannot be used as a pawn in some armchair morality action, no matter how well elected officials feel it may poll.

I was pretty quick to jump on this on Twitter, mostly out of anger, and given the retweets and favorites from my meager following (particularly from the accessibility community) I suspect I am not alone. Feel free to retweet it to your followers (or write your own):

A quick Google search (or use your own search terms) will net you many results from people who think Verizon's reported argument is absurd (Won't somebody please think of the childrendisabled?).

I don't think my blog post, which ranks nowhere on Verizon's radar, will do much to sway its nor the FCC's opinion, but I do want to make sure I add to the growing chorus of people publicly denouncing something Verizon is arguing behind closed doors.


In April I wrote a post about net neutrality (We Need to Raise a Stink about Net Neutrality) where I asked people to tweet to Tom Wheeler and the FCC. In it I include plenty of references and arguments, but this video from Last Week Tonight with John Oliver (which I amended to my original post) does a better job of explaining net neutrality:

As John Oliver suggests, you can leave our own comments at the FCC site. As of a week ago there were 49,206 comments. As of this writing there are 115,213 comments. Only the most recent 10,000 comments are available to be viewed, which I cannot explain. Further, if you want to consider accessibility, as Verizon seemingly does, you may want to also ask the electronically filed responses be made available in a format other than PDF.

Update: July 25, 2014

Perhaps in reaction to the Verizon rumors, or just because the cause makes sense, on July 18 five different organizations related to accessibility filed their own joint comments with the FCC. The organizations are: Telecommunications for the Deaf and Hard of Hearing, Inc. (TDI), the National Association of the Deaf (NAD), the Hearing Loss Association of America (HLAA), the Deaf and Hard of Hearing Consumer Advocacy Network (DHHCAN)), and the Rehabilitation Engineering Research Center on Telecommunications Access (RERC-TA) along with Professor Clayton Lewis. Together they filed a brief, which you may read online (and which I have copied locally as I suspect this URL will be allowed to rot by the FCC), outlining their support of net neutrality. An excerpt:

[We] seek to promote equal access for the 48 million Americans who are deaf, hard of hearing, late-deafened, deaf-blind, or deaf with mobility or cognitive disabilities to the informational, educational, cultural, and societal opportunities afforded by the telecommunications revolution.

The letter outlines six arguments in particular, with far more detail in its sixteen pages:

  1. Retaining and improving transparency rules will improve the ability of consumers who are deaf or hard of hearing to access the Internet on equal terms.
  2. A no-blocking rule would help ensure the availability of accessible telecommunications services for consumers who are deaf or hard of hearing.
  3. The Commission should bar paid prioritization while ensuring that Internet-based services and applications are accessible to consumers who are deaf or head of hearing.
  4. Title II reclassification would afford the Commission additional flexibility to ensure that broadband services are accessible, and the Commission should exclude accessibility-related Title II provisions from forbearance if it reclassifies.
  5. The Commission should ensure that the enterprise services and premise operator exceptions avoid facilitating illegal discrimination against people who are deaf or hard of hearing.
  6. The Commission should ensure that the use of data caps do not result in discrimination against people who are deaf or hard of hearing.

The same day, the American Association of People with Disabilities and the National Council on Independent Living also filed their own joint letter with the FCC (also available from a non-FCC URL). In addition to an open internet, the letter argues for an ombudsman:

Over the past few years, Congress shifted the focus of universal service from mere availability to adoption and utilization. […] This important review of Open Internet policy provides an opportunity to ensure that people with disabilities have full and open access to broadband communications and enjoy the important consumer protections mentioned in our comments. […] An Ombudsman Office Can Monitor and Report on Access Issues Associated with Consumers with Disabilities

Ars covered the latter filing in its Tuesday post, "Deaf advocacy groups to Verizon: Don’t kill net neutrality on our behalf."