
The slides and video from my talk (a little background).
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.”
The slides and video from my talk (a little background).
In addition to the slides, I've embedded video of my talk and way too many tweets after that.
Impressing everyone on the internet, Paul Klipp has already gotten videos from ACE! posted less than 24 hours after the event ended. That's impressive. I understand his tactic is to upload lower resolution videos immediately and then slowly replace them with higher resolution videos. Depending on when you see this, it may still be the low-res video.
Tweets from ACE! that satisfy my ego, show me in a photo, or might be funny.
It's all about trust. RT @aardrian: Speaker prep with @lissijean at #aceconf. pic.twitter.com/xUMU2aaFbM
— Gil Zilberfeld (@gil_zilberfeld) March 16, 2015
Starting the day with @Kel_Moran @zuzuzka @aardrian and @mattlangholz #aceconf pic.twitter.com/0SN3fOdZx7
— Gil Zilberfeld (@gil_zilberfeld) March 16, 2015
.@gil_zilberfeld @aardrian I found the projector for #aceconf pic.twitter.com/f4NX07edmw
— Melissa Perri (@lissijean) March 16, 2015
@aardrian is about to start his talk about selfish accessibility. Making software accessible for people with disabilities is very important.
— Adam Boczek (@nativeagile) March 16, 2015
Now with @aardrian 'Selfish Accessibility' #aceconf pic.twitter.com/mNu7rpOrxX
— Gil Zilberfeld (@gil_zilberfeld) March 16, 2015
Developers were doing better caring for users with some kind of impairment if they tried to put themselves in that position. #aceconf
— Andy Brandt (@andybrandt) March 16, 2015
An interesting take on "situational disability", like being a keyboard user when eating with your mouse hand. @aardrian #aceconf #acecon
— Andy Brandt (@andybrandt) March 16, 2015
Be selfish: write software for the future, maybe injured, maybe encumbered you. #aceconf @aardrian
— Gil Zilberfeld (@gil_zilberfeld) March 16, 2015
"Selfish #a11y" by @aardrian at @aceconf pic.twitter.com/Xu096Tad0Q
— Grzegorz Rożniecki (@xaerxess) March 16, 2015
"users do not report what they are actually doing" @aardrian (hence user observation so important) #aceconf #acecon
— Andy Brandt (@andybrandt) March 16, 2015
Very interesting talk by @aardrian about software and disabilities and how to test it in this context. #acecon pic.twitter.com/tzwaRmw2Tx
— Adam Boczek (@nativeagile) March 16, 2015
@aardrian Great tip - I will start stealing colleagues's mice in the interest of accessibility. #aceconf
— Kelly Moran (@Kel_Moran) March 16, 2015
Eating out #aceconf with @nativeagile and @mattlangholz pic.twitter.com/K3CdKcjQuu
— Gil Zilberfeld (@gil_zilberfeld) March 16, 2015
Todays speakers pitching their talk for clarity. An agile conference being agile after feedback, brilliant! #aceconf pic.twitter.com/pkLqZUjrCk
— vince baskerville (@whoisvince) March 17, 2015
"Be the Placebo" via @aardrian #aceconf
— Gil Zilberfeld (@gil_zilberfeld) March 17, 2015
3 out 3 speakers now agree: "The mic tried to crawl into my mouth". #aceconf
— Gil Zilberfeld (@gil_zilberfeld) March 17, 2015
Thanks @paulklipp for an awesome #aceconf! You are the calmest conference organizer I have ever met and everything was great!!
— Melissa Perri (@lissijean) March 17, 2015
Last night out with the speakers at #aceconf @RisingLinda @paulklipp @aardrian @gil_zilberfeld @Kel_Moran @whoisvince pic.twitter.com/XuDx4IxpOQ
— Melissa Perri (@lissijean) March 17, 2015
The #ACEconf 2015 videos are being uploaded here: https://t.co/ZQuiIWmXcR #omgkrk
— ACE! Conference (@aceconf) March 18, 2015
Ideas from #aceconf speaker dinner: hire clowns as subjects for usability tests. Cheaper; tests task focus of other participants.
— Adrian Roselli (@aardrian) March 17, 2015
Ideas from #aceconf speaker dinner: Selfie sticks can double as marshmallow skewers. Handy at parades where floats catch fire.
— Adrian Roselli (@aardrian) March 17, 2015
Ideas from #aceconf speaker dinner: Tiramisù may or may not be cheese cake.
— Adrian Roselli (@aardrian) March 17, 2015
I've received the audience feedback from my talk and overall was pleased. 17 people responded (out of what I estimate was ~40+ in the room) with the following rankings:
Of those 17, 10 left comments (which I greatly appreciate!). Sadly, the one Hate it vote did not leave any comments.
The two Meh comments are mostly out of my control. I was given a 30 minute slot, which I agree is too short for all that can be said on the topic. As for the commenter who claims he/she won't be able to use it, I feel that the testing parts of my talk at the very least are in everyone's reach, so I think it comes down to deciding to use it. Even if only to troll the Virgin America site.
I'll fill this up with notes and other content later, but in the meantime here are the slides from my talk this morning:
I've written a bunch of handy stuff on print styles, here are some links (or you can see all posts tagged print
on my blog) along with other resources (most of this is referenced in my slides):
Booster had a lot of activity on Twitter (not just about my talk, imagine that). I've collected some of the tweets below.
How about this: not 1 but 2 evolters speaking at @boosterconf today! Give a big Bergen welcome to @aardrian and @martinburnssv!
— evolt_org (@evolt_org) March 11, 2015
If your site doesn't support the printer it's not responsive. @aardrian #booster2015 #RWD
— Tin Kadoic (@tinkadoic) March 11, 2015
I can guarantee you that people print your site more often than they click your carousel! @aardrian #booster2015
— Regine Sagstad Berg (@reginesagstad) March 11, 2015
#booster2015 lightning talks ⚡️ from @aardrian, @ramyo, @hallvaren & @sivmhollup. pic.twitter.com/UYdIrIwLJe
— Elisabeth Irgens (@elisabethirg) March 11, 2015
@aardrian Responsive also means printable. Loving #booster2015 already!
— Siv Midtun Hollup (@sivmhollup) March 11, 2015
“…after more than a decade of support for print styles, (@RWD advocates) still forget…” http://t.co/maGjWh66BP
ht @elisabethirg @aardrian
— David G. Smith (@iDGS) March 11, 2015
While Opera chose not to greet me upon my arrival in Norway, somebody must have sent former employee @lasmagnu to chat at dinner.
— Adrian Roselli (@aardrian) March 11, 2015
Open space at #booster2015 run #leancoffee stylee, with @ourfounder @jrothman @mattbarcomb @aardrian @andrev & others pic.twitter.com/dWGcGd7V77
— Martin Burns (@MartinBurnsSV) March 12, 2015
I got feedback from my talk, and it was overwhelmingly positive. Consider mine was the first lightning talk of the first session of the first day immediately after the keynote, I'm just pleased people took a moment to vote.
Voting consisted of asking attendees to drop a colored card into a basket representing my talk. There were three options. I got 15 green cards (it was amazing
), 4 yellow cards (it was okay
), and no red cards (I didn't like it
).
Only one person left a comment, which was Talked too fast.
I cannot disagree with that. With 10 minutes to cover 42 slides and do so to an audience of non-native English speakers, I'm thrilled I only received that comment once (though I suspect many others agreed).
Making Your Site Printable - Adrian Roselli from Booster conference on Vimeo.
This is a follow-up to my post CSS Bookmarklets for Testing and Fixing.
While surfing Medium the other day I chose to read a comment. As usual, the comment overlay came up at the bottom of my screen with an option to see replies. When I tapped the replies link, I was immediately prompted to log in. This was new.
In the time between me tweeting Medium to complain, and them responding that it was a bug, I wrote a bookmarklet to remove that login overlay.
This was the easy part. The hard part was using the bookmarklet on my mobile.
As you may already know, there is no bookmark bar in the average mobile browser (at least not on smaller screens). Viewing bookmarks will generally take you to a new tab or screen, meaning a bookmarklet cannot affect the page you were viewing.
Conveniently, once you create a bookmark it becomes available through the auto-complete feature of the browser address bar. In this case, while viewing the page I tapped the address bar and started typing the name of my new bookmarklet. It helps that I remembered this, otherwise it might have taken more time.
Hopefully by the time your read this Medium will have fixed the issue. If not, here is the bookmarklet I use:
javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('.overlay{display:none !important;}',0);})()
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Fix Medium
Of note: after you do this, the hit state of the View n replies
link is partially blocked. You need to tap at the very top of the link. If that requires too much precision, then zoom in until it it wraps to two lines and tap the top line of text.
Christian Heilmann wrote a great post on the web application myth, which may be the title, though I can't be sure because Medium's URLs never match what may be the page title, which is denoted by an h3
because there is no h1
nor h2
on the page...
Anyway, regardless of title, go read what I'll title The Web Application Myth: Web applications don’t follow new rules.
I regularly have to test sites in development, review some third-party site, or just use a site in my day-to-day time wasting (and banking) rituals. I've relied on viewing the page's source or popping into my browser's dev tools to find a missing element, copy un-transformed text, check for inline styles, and so on. Typically I am relying on CSS and not JavaScript, as that is where I excel.
I got a little annoyed doing that all the time, and this morning I had reason to visit Pinterest and mostly lost my marbles at its login overlay and refusal to scroll. So I channeled that rage and taught myself to build a bookmarklet to dump that Pinterest overlay crap. I have created a few more that include my standard styles for testing, styles that perhaps you (dear reader) will find useful.
I'll have basic instructions below showing you how you can build your own and/or modify the ones I've provided.
Note that I say may steal. That's me giving you permission. Note that I call them bookmarklets. That's me not giving into the term favelets or whatever HotJava called them (was it hot links?).
You know what's cool? Removing link underlines and providing terrible link color contrast. It's so cool, in fact, that I want to make those sites less cool. As well as usable. Read my rant on this.
This bookmarklet restores link underlines across the board. Every link. After all, if you want the link underlines, you probably don't care that the designer would freak out at the noise it adds to the page.
javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('a[href]{text-decoration:underline !important}',0);})()
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Link Underlines
Just as cool as removing link underlines is removing the outline on elements that get focus as you tab through a page. After all, if you've hidden the links, why not hide when the links are selected. Virgin America tends to agree.
This bookmarklet not only restores the outline (in the form of the two-pixel dotted blue line), but also adds a drop shadow for those cases where the blue is lost against the surrounding colors.
javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('*:focus{outline:2px dotted #00f !important;box-shadow: 0 0 2em rgba(0,0,0,.75) !important;}',0);})()
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Focus Outlines
Over at Algonquin Studios we have worked in the content management space for, well, since the dawn of content management systems. One of the risks of using a CMS is that your authors may accidentally (or intentionally) embed styles whether by pasting rich-text from elsewhere or by features built into the WYSIWYG editor within the tool. This is most common with text styles.
Sometimes it is faster to just find the elements that have a style
attribute on them, as that's the first clue that there may be a conflict that needs to be corrected. This option will find any of those elements and give them a yellow background along with a two-pixel dotted red border (like the Windows "hot dog" theme from the previous century).
javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('*[style]{border:2px dotted #f00 !important;background-color:#ff0 !important;}',0);})()
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Inline Styles
In ARIA, there are a few instances of roles that should only appear once on a page. These landmark roles are banner
, contentinfo
, and main
. In addition, the W3C HTML5.1 specification notes that there must be only one main
element per page.
This bookmarklet will identify any additional instances of any of the once-per-page items above. If you know enough about coding ARIA, then you probably know enough about finding which of the roles/elements is on repeat. Offending items will have a two-pixel dotted red border and red background.
javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('*[role=main]:nth-of-type(n+2),*[role=banner]:nth-of-type(n+2),*[role=contentinfo]:nth-of-type(n+2),main:nth-of-type(n+2){border:2px dotted #f00 !important;background-color:#f00;}',0);})()
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Duplicate ARIA
An image without an alt
attribute can be anything from an annoyance to a barrier to those using assistive technologies. Being able to quickly identify those images on a page can save time when figuring where to focus your efforts.
This bookmarklet will find those images and give them a two-pixel dotted red border. Note that it only looks for images with a missing alt
, as a blank alt
attribute is often perfectly valid.
javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('img:not([alt]){border:2px dotted #f00 !important;background-color:#f00;}',0);})()
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Missing @alt
Sadly, it is not uncommon for sites to reset the default size of the text on the page. Too often that is done to satisfy a design change. One site where I find the text too small to read comfortably, or at all, is Daring Fireball. I know I am not the only one to feel this way.
This bookmarklet will resize the text on the body
element to 100%, ideally conforming to whatever your default browser preferences are. It works great on Daring Fireball, but could easily be overridden on sites that set the text size in other ways and/or on other elements.
javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('body{font-size:100% !important;}',0);})()
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Reset Text Size
It is not uncommon for a WYSIWYG editor in a CMS or on a comment site to throw extra empty p
elements into the content. While I once wrote a style into my development CSS to highlight these issues, I was reminded of the potential utility by a Happy Cog post on pseudo classes.
This bookmarklet will find elements that are empty — no content, no whitepsace. It will not highlight images (by excluding elements with a src
attribute) nor form inputs (by excluding elements with a type
element), two common self-terminating elements that will otheriwse trigger this. It isn't perfect, but you are welcome to make it your own.
javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('*:not([src]):not([type]):empty{border:2px dotted #00f !important;background-color:#00f;}',0);})()
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Find Empty Elements
When you visit Pinterest without a Pinterest account, or without being logged in, you are prompted to sign up/in by a terrible overlay. In addition, the page won't scroll past a certain point. This annoys me. So I made a bookmarklet to remove the two overlays and re-enable scrolling. You can test it on my abandoned Pinterest page.
javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule('.Modal, .UnauthBanner {display: none !important;}',0);b.insertRule('.hasFooter.Grid.Module{overflow-y:visible !important;}',0);b.insertRule('.noScroll{overflow:auto !important;}',0);})()
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Fix Pinterest
If you look at the code chunks above, you'll see I am doing the same thing over and over. I am using the JavaScript CSSStyleSheet.insertRule()
method to insert a new style rule into the page's stylesheet. Not only does the Mozilla Developer Network have a great overview with sample code, but David Walsh shows similar code with some minor tweaks.
This approach allows me to leverage my CSS skills to write selectors to find and style elements on the page. Since CSS has so many powerful selectors, I find this easier to quickly repurpose. In addition to adding a new style, I always include !important
with each so that it will override any inline styles.
If you are writing a function from scratch, make sure you minify it to take up less space (you may bump into character limits for a bookmarklet). Pre-pend javascript:
and make it the href
value of a link and you are done.
Here is a sample block of code you can use with the styles rendered in bold so you can replace them with your favorite selector. In this example I have two style rules so you can see how to add additional selectors.
javascript:(function(){var a=document.createElement('style'),b;document.head.appendChild(a);b=a.sheet;b.insertRule("a[href]{text-decoration:underline !important}",0);b.insertRule("*[style]{border:2px dotted #f00 !important;background-color:#f00;}",0);})()
And with that you should be off to the races.
Links to my posts referenced above:
It's hard to use bookmarklets on mobile devices, but I have a solution.
If you have to wear a ring, then perhaps you have experienced the discomfort of putting a cold ring on your finger (maybe in the morning in a cold house). I decided that I could do something about that using the only tool in the modern developer's toolbox — the smartphone app.
I'm kicking off the new year by announcing that my Ring Warmer app is done. Well, it's a web app. Actually, it's just a web page. Living as nothing more than a block of code at CodePen. Regardless, I started this in late 2012 and then mostly forgot about it, so I'm thrilled to call it done.
The opening image is an animated GIF that shows how one might use the Ring Warmer app. I've also embedded the same animation as an Instagram video (or view it directly on Instagram):
The idea here is that you can choose a ring size and a warmth level, place your ring in the designated spot, and wait patiently for it to work its magic.
The idea is, of course, absurd.
In the strictest sense, it can work. At the lowest setting (warm), only the red LEDs will light up, carrying one-third of the total heat a pixel can produce. As you move to the highest setting (hottest), all the LEDs are lit to generate white, so each pixel is producing its maximum heat as the red, green, and blue LEDs are all lit.
Of course, the amount of heat this carries is negligible. You will transfer more heat to the ring from the warming battery than from the pixels. The ring itself might not get very warm unless you also fire up the radio antenna (I left that feature out as a courtesy).
Now that I've gotten as much pranking out of this fake app as possible, I figured I'd at least write it up a bit.
Very simply, I use a border radius with some box shadows to make the glowing ring. Then I drop the white glowing dot (using box shadows and border radius) onto one edge and rotate the entire thing in perpetuity. It's a mess of mixed sizing units, questionable animation syntax, and useless elements.
Then I made a form so you can change the ring size and the temperature. The ring size isn't matched to any real measurements, except in Chrome on my Samsung Galaxy S4 the default size matches my ring. All sizing after that is based on ems, so it doesn't scale like a real ring. The temperature change is nothing more than colors with CSS transitions and some JavaScript that sets explicit styles instead of classes. In other words, it's a terrible idea to copy this code.
Regardless, here's the pen in action:
See the Pen Ring effects by Adrian Roselli (@aardrian) on CodePen.
This will not be available in any app store. You can load the pen in full screen view to trick your friends if you are that bored.
For a few years now web developers around the world have celebrated
Saturnalia Christmas with advent calendars covering topics related to the web. Some come and go, but you'll probably recognize a few regulars on this list.
I may have missed some, so please pass them along if you know of any. As I learned in prior years where I have tracked them, I don't know them all on December 1, and update accordingly. Some of this is because the sites don't promote the new calendar on the home page.
24 Ways, the one that most of this think about for web development calendars, is back again. It's been going strong since 2005 and based on its history this year should have some good articles.
Perl Advent Calendar goes all the way back to 2000 (and back then looked a bit more like a traditional advent calendar, too) and has been dispensing tips for Perl developers ever since.
24 Jours de Web is starting its second year as an advent calendar for web folk. Written in French, it is clearly primarily targeted at French speakers, but a round of Google Translate will open it up to far more readers (like me).
UXmas is an advent calendar aimed at the user experience community. Coming from Australia, American readers may be thrown just a bit by the schedule. The calendar promises everything from sketches, to articles, to tools, to videos.
Webkrauts has an all German advent calendar, and it also dates back to 2005. It covers general web topics, but being in all-German readers like me will benefit from a Google Translate version of the page.
Web Accessibility Advent Calendar 2014 is in Japanese, and thanks to the wonderful powers of Google Translate, I can tell you that it is a calendar to make the talk about Web accessibility (based on this statement: Webアクセシビリティに関する話題でつくるカレンダーです。
). If you know Japanese, I welcome any corrections. The site Adventar.org appears to host other advent calendars, some about web technologies, some about ramen.
24 Pull Requests is less an advent calendar than it is an effort to mobilize developers. The goal is to get developers to send a pull request every day in December (up to Christmas), thereby supporting your favorite open source projects. There are even Coderwall badges for those who collect those sorts of things.
SysAdvent is targeted to systems administrators, but there is a some cross-over to web developers. It has posts dating back to 2008, so there is plenty of good material there if you're too impatient to wait for each day to be revealed.
Håkan Forss's lean/agile calendar was recommended to me by Martin Burns, to whom I generally listen on this topic. Håkan is an Accredited Kanban Trainer (AKT) and a Kanban Coaching Professional (KCP), and his first post seems pretty good, so I've added it. Also, LEGOs.
Performance Calendar hails this as the speed geek's favorite time of the year, ostensibly because of the tips it has been offering each December since 2009. It isn't just server optimizations you'll find here, so don't shy away because you're not a system admin. While I had it last year, it hadn't launched when I posted this, so I've rectified that.
The Free Font Advent is providing information on and links to, you guessed it, a free font every day. The site is in German, but Google Translate will be more than enough to get the narrative written for each typeface. I picked this one up from Deborah Edwards-Onoro's advent calendar post.
AWS Advent is dedicated to sharing information on features and services available from AWS. If you are an AWS user and have something to offer, as of this writing there are still five slots open for contributions. I also picked this one up from Deborah Edwards-Onoro's advent calendar post.
The Royal Institution has something called Things to Do with Stuff that might be like an advent calendar, given this statement: Throughout December inspired by the 2014 CHRISTMAS LECTURES, we're releasing little nuggets that'll encourage you to interact with and understand the tech that surrounds us.
The very first item is how to make a movie projector with a smartphone, a magnifying class, and a box.
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 table
s, 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).
The animated screen shot is from a Pen that I created to show the effect. I have embedded it below, though you can visit (and fork) the pen directly at CodePen.io.
There are also two open Chromium bugs and one Stack Overflow discussion that are related, though not just with single-pixel gradients.:
Notes on the first bug offer an explanation of sorts:
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.
See the Pen Testing Gradients as Column BG by Adrian Roselli (@aardrian) on CodePen.
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 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.
There are links peppered throughout, but there are so many more I could add. Feel free to suggest more if helpful.
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):
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):
Congrats to @gdiBuffalo attendees @dennrodriguez & Elizabeth Canas for winning tickets to tomorrow's #CSSSummit. Perhaps they'll heckle me.
— Adrian Roselli (@aardrian) July 14, 2014
Good luck with your talk @aardrian! Thanks again for giving away two tickets to #CSSSummit ! #womenwhocode #buffalo
— Girl Develop It Bflo (@gdiBuffalo) July 15, 2014
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:
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:
So let's build a good print stylesheet for a website. A nice slide deck by @aardrian. http://t.co/TJW7uvu99z
— Smashing Magazine (@smashingmag) July 19, 2014
Web builders spend hours on carousels & maybe 1 hr on print CSS even though visitors print more than engage a carousel —@aardrian #CSSsummit
— Christopher Schmitt (@teleject) July 15, 2014
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.
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.
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:
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.
Hey @VirginAmerica, to help you fix your lack of keyboard access, I left a bug report for you at @webcompat: webcompat/web-bugs/issues/141
— Adrian Roselli (@aardrian) June 18, 2014
Hey @VirginAmerica, I left a comment about your lack of keyboard access at that Wired gush-piece: http://t.co/9RAjaLcAdS
Just trying to help
— Adrian Roselli (@aardrian) June 17, 2014
Seriously, @VirginAmerica, just go into main.css (https://t.co/E1Jh0qSu74) and *at least* delete this:
a:focus{outline:none}
2 minutes.
— Adrian Roselli (@aardrian) June 16, 2014
Useless for keyboard users. RT @RWD: […], so I missed that the new responsive @VirginAmerica site went live! http://t.co/RM1tikjo14
— Adrian Roselli (@aardrian) June 16, 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?
It took just over a month, but Virgin America responded to me:
@aardrian Thanks for your feedback on the #VXnewlook Please follow + DM if you'd like to share more.
— Virgin America (@VirginAmerica) July 21, 2014
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:
Use this ONE WEIRD TRICK to make your sites keyboard friendly:
Delete this:
:focus {outline: none}
— Adrian Roselli (@aardrian) July 17, 2014
Marcy Sutton, at the JSConf, provided a walk-through of the Virgin America web site experience using a screen reader. It does a great job of showing what a terrible experience this site has created. I've embedded it below, bracketed to the relevant part of her talk, or you can view it directly on YouTube (starting at 0:20).
Here is a video of the screen reader walk-through, pulled from the latest version of Marcy Sutton's slides on Angular Accessibility:
This post originally appeared on the Algonquin Studios blog.
If you work much with accessibility, then you might consider the title of this post to be an oxymoron, a self-contradicting mess. Frankly, I tend to agree. Barring a compelling use case, I never start a project with Bootstrap and I resist including it when explicitly requested (so far successfully in nearly every case). Of a few reasons, accessibility is the biggest issue I have with it.
There are, however, a couple options to mitigate the accessibility mess that is Bootstrap.
I should note that this post is a follow-up to the Q&A after my talk at HTML5 Developer Conference, Selfish Accessibility, where I gave some advice about Assets which, at the time, was using Bootstrap 2 (it has since moved to version 3).
The Centers for Medicare & Medicaid Services (CMS), a division of the US government (specifically HHS), has emerged as an unexpected champion of accessibility for Bootstrap and made its own framework, Assets (first announced in late 2012). This may not be a surprise to many when you consider CMS's role working with people who are older and/or in need of some form of medical assistance (equipment or services). Arguably, its constituency stands to benefit the most of any division of the US government.
Assets was just updated to use Bootstrap 3 (which should make many a Bootstrap user happy). Assets promises you:
Section 508 compliant, cross-browser compatible UI components that you can use in your accessible web site or web application. Assets is an accessible, responsive, modern framework.
If you are an organization that works with the federal government to build web-based applications for the general public, then it may be a no-brainer to use this framework. Arguably your Section 508 accessibility requirements are met to a high degree, and where the framework fails you may be able to make a case that you are using a government-sanctioned tool. It doesn't let you off the hook for more fundamental accessibility failures (color contrast, images as text, infinite scroll, etc.).
The accessibility statement identifies the profiles used for testing. The documentation page links to all the UI components, which is handy. Jennifer Sutton has also provided links to tests she made with the calendar widget over at the WebAIM mailing list (though she was using version 2).
There are some caveats. On the spectrum of Internet Explorer versions, it only supports version 8 and above (the last version, built on Bootstrap 2, also only supported IE8+). The files are served from a US government CDN, which while not bad in and of itself, should require you to test them to make sure it serves the files as well as a commercial CDN. For example, icon font FontAwesome is served via the Assets CDN, though you may want to compare against others given its ubiquity on the web.
The Assets documentation also provides links to a Medicare style guide and a Healthcare.gov style guide, both of which require a login to see, severely limiting their value to sub-contractors.
If you refuse to use anything from the US government, you can head to the other end of the spectrum and use the accessibility plug-in from PayPal.
According to PayPal:
This plugin adds accessibility mark-up to the default components of Bootstrap 3 to make them accessible for keyboard and screen reader users.
Because it's an add-on to your existing Bootstrap 3 code, it should just work. It will make the following default UI components accessible: Alert, tool-tip, pop-over, modal dialog, drop-down menu, tab panel, collapse, and carousel. You can pop over to the demo page and test it out with and without the plug-in (use a keyboard to understand the benefits).
As with Assets, this doesn't guarantee that what you build will be accessible. You still need to consider the same items I cite above along with many many more accessibility elements which cannot just be handled with a plug-in nor a checklist.
The Canadian government has created its own framework, also intended to be accessible, usable, interoperable, mobile friendly and multilingual. The Web Experience Toolkit (WET) has just moved up to version 4.
While not a framework nor an accessibility add-on, the United Kingdom has a handy style guide to make all its gov.uk properties look consistent: GOV.UK elements
There may be hope for government web sites after all, though just don't try to use Section508.gov with a keyboard.
Heydon Pickering has updated his Revenge.css to work with some Bootstrap shortcomings. If you aren't familiar with Revenge.css, it's a handy CSS file you can call via a bookmarklet to highlight accessibility issues in your CSS file (like removing outlines, or forgetting the :focus
selector when you use the :hover
selector).
In my post What to Consider before Using Free Getty Images one of the many caveats I outlined was the lack of responsive support in Getty's iframe
code. Of all the issues I raised, this one is actually pretty easy to get around.
While the other points still preclude me from readily using Getty image embeds, I recognize its value to clients and want to be able to allow them to use these images without fear of breaking the responsive sites we've coded. I also wanted a solution that won't require my clients to do any extra work, such as embedding HTML wrappers, adding classes or IDs, inline script, or generally mucking about in code.
If you've read at least a few of my last 15 years of writing, you might know I have a general aversion to scripted solutions and generally start trying with a CSS solution. At first glance, there is an example dating back five years at A List Apart that I thought might work, Creating Intrinsic Ratios for Video.
Another post tackled other embeds (Vimeo, Slideshare) in 2011 using the same technique expanded just a bit. Five years on and a new article popped up (just a couple weeks ago, Making Embedded Content Work In Responsive Design) that is targeting more third-party embeds (calendars, Google Maps), but leans on the A List Apart technique — and by leans on
I mean just uses it outright but for more services.
The A List Apart solution and its variations don't work for two reasons: 1) they violate my requirement of not making my authors create HTML and 2) they rely on knowing the ratios. Every Getty image can have its own aspect ratio that I can't expect my authors to calculate.
The Getty embed has another factor not accounted for in these other solutions — regardless of the image aspect ratio, there is always a credit box below the image at a seemingly fixed height. This bar will always occupy that height, so scaling the image's height based directly on its width ends up leaving an ugly vertical white bar on the right of the image. This precludes any simple ratio as a solution.
I made a demo to show my solution (does not open in a new window).
I decided the best approach was to write a JavaScript function that accounted for the height of the image credit as it calculated the image ratio. Then it would apply width and height styles that would scale the embed without leaving the ugly white gap on the right (barring rounding errors, which are evident in the portrait images).
I opted for JavaScript instead of a block of jQuery because I knew this would be maybe a dozen lines of code in total, and requiring an additional 29-82KB (depending on your minification and zippage) for the jQuery library is, well, absurd. Also, I am not a fan of dependencies, particularly when most developers rely on hosted libraries.
I did some screen captures of Getty image embeds and identified the image credit bar is 69 pixels tall. That number may (will) change in the future. You may want to populate that variable from your chosen CMS so you don't have to do a full testing and deployment pass just to update one variable in your JavaScript functions file or page template (across all your sites) when Getty inevitably changes it.
The Getty iframe
has no unique ID
or class
to make it easy to identify on the page, nor any other unique attributes, with the exception of the src
attribute. So I loop through all iframe
s on the page and only grab those with the Getty URL.
I then get the iframe
's width
and height
attributes, subtracting 69 from the latter, and calculate the ratio. From there I scale the iframe
to 100% width and then get its new pixel width to feed to the ratio to calculate what its new height should be, finally adding 69 to it.
In my example page, I call the function at the bottom of the page and also in an onload
in the body
. There are better ways to do this, but given all the variations that are already out there (and that you may already employ), I leave it to you to figure out the best approach to handle for users who resize windows or rotate their phone/tablet.
What is compelling to me about this solution is that my clients (site authors) don't need to worry about adding or modifying any HTML on the page (most don't know HTML anyway), let alone CSS or script. When they paste the embed code, it should just work.
function responsiveGetty() {
try {
// Get all the iframes on the page.
var iframes = document.getElementsByTagName('iframe');
// Height in pixels of the Getty credits/share bar at the time of this writing.
var crHeight = 69;
for(var i = 0; i < iframes.length; ++i) {
// Check to see if it's a Getty embed using the only attribute that's unique, the src.
if(iframes[i].src.indexOf("//embed.gettyimages.com") != -1) {
eachIframe = iframes[i];
// Get the current ratio after excluding the credit bar.
picHeight = eachIframe.height - crHeight;
picRatio = picHeight / eachIframe.width;
// Set the iframe to fill the container width.
eachIframe.style.width = "100%";
// Set the iframe height to correspond to the ratio, adding back the credit bar height.
eachIframe.style.height = ((picRatio * eachIframe.offsetWidth) + crHeight) + "px";
}
}
} catch(e) {}
}
responsiveGetty();
There are probably ways to optimize my code or factors I did not consider. If you see something wrong or that could be improved, leave a comment.