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 Paciello Group is holding a full day of free webinars on Global Accessibility Awareness Day. That's 24 straight hours of talks, which started at midnight (GMT) on Wednesday, May 20 through through midnight (still GMT) on Thursday, May 21. I was fortunate enough to participate as a speaker and had the third slot in the queue.
As promised, I posted my slides. All the links I referenced are embedded within.
Tweets!
I'm pleased to see there was tweet activity during (and about) my talk. I've captured many of them below.
In his Selfish Accessibility talk @aardrian is giving us figures about disability in the US
It's just impressive #a11y#ID24
In addition to the slides, I've embedded video of my talk and way too many tweets after that.
Video
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
Tweets from ACE! that satisfy my ego, show me in a photo, or might be funny.
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:
Loved it! 10
Liked it: 2
Meh: 4
Didn't like it: 0
Hated it! 1
Of those 17, 10 left comments (which I greatly appreciate!). Sadly, the one Hate it vote did not leave any comments.
Liked it: Too basic for me, but nice examples of disabilities.
Loved it! I loved the idea how to easily test your apps.
Loved it! Great that this topic emerged.
Loved it! Great approach to creating sites/apps friendly for impaired.
Loved it! Full of very practical suggestions. Thanks for including it.
Loved it! Content that usually doesn't get a forum.
Meh: Interesting, however I won't get a chance to use what I learned.
Loved it! Interesting point of view. I did not consider accessibility during software design. I should start.
Liked it: Most important is to think about problem, not about product/project.
Meh: Nicely said, but too short.
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.
Animated image showing the Pinterest site and its infuriating blocking overlay, which is removed with the bookmarklet below.
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.
Bookmarklets You May Steal
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?).
Restore Link Underlines
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.
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Link Underlines
Restore Focus Outlines (or Fix Virgin America)
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.
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Focus Outlines
Find Inline Styles
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).
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Inline Styles
Find Duplicate ARIA Roles
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.
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Duplicate ARIA
Find Missing Alt Attributes
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.
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Missing @alt
Reset Text Size (Added January 30)
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.
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Reset Text Size
Find Empty Elements (Added May 6)
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.
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Find Empty Elements
Fix Pinterest
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.
Copy or drag the link to your bookmarks, or make a new one and paste the code from above: Fix Pinterest
Make/Modify Your Own Bookmarklet
The Virgin America site is made usable for those who navigate with a keyboard by restoring link underlines and adding focus styles to elements.
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.
Way back in October I noticed this WHATWG HTML bug (26942) where someone asked why do these examples of <html> lack the lang attribute? I thought the answer from Hixie was a bit dismissive and not based on any data or real-world benefits of use, particularly in the context of screen readers:
Why not? Realistically, few people include it. It just means the language is unknown.
At the time, I could not get the latest archive to download from WebDevData.org (though that has changed, see below), so I fell back to asking for help on why the lang attribute is valuable.
How the lang Attribute on <html> Is Used
I got lots of good bits of feedback, which I collected into a Storify. I've distilled all that great information to these key points:
VoiceOver on iOS uses the attribute to auto-switche voices.
VoiceOver can speak a particular language using a different accent when specified.
Leaving out the lang attribute may require the user to manually switch to the correct language for proper pronunciation.
JAWS uses it to load the correct phonetic engine / phonologic dictionary — Handy for sites with multiple languages.
NVDA (Windows) uses it in the same way as VoiceOver and JAWS.
When used in HTML that is used to form an ePub or Apple iBooks document, it affects how VoiceOver will read the book.
Firefox, IE10, and Safari (as of a year ago) only support CSS hyphens: auto when the lang attribute is set (not from Twitter; source).
In the absence of setting a lang attribute on the <html> element, screen readers will fall back to the user's default system setting (barring any custom overrides) when speaking content.
How Many Pages Use lang
On January 8, WebDevData.org (from a W3C Community Group) posted its latest archive (which did not error on download, woo!). It consists of the HTML from 87,000 web pages.
I pulled down the 780MB file and re-taught myself the skills necessary to parse the files. For those who are regular expression geniuses, you are welcome to suggest an alternate approach, but I used the following pattern to return all the <html> elements: <html([^>]+)>. It fails for any <html> with no attributes at all, but for what I am doing that's ok.
Of the 84,054 pages I parsed (I excluded XML, ISO files, and so on), I found that 39,433 use the lang attribute on the <html> element. That's just about 47% (46.914% if I understand significant digits correctly).
What that tells me is that instead of the case being that few people include it, nearly half the web includes it.
There are 12,672 instances of xml:lang, though at a quick scan they appear alongside lang. If anyone with better regex skills would like to help me further parse, please let me know.
Why You Should Use the lang Attribute on the <html> Element
Hyphens
By using lang, you get the benefits of hyphen support in your (modern) browser that you otherwise would not get (assuming you use hyphens: auto in your CSS).
Accessibility
At the very least, lang is a benefit for screen reader users, particularly when your users don't have the same primary language as your site. It allows proper pronunciation and inflection when the page is spoken.
WCAG Compliance
Including the lang is a Level A requirement of the Web Content Accessibility Guidelines 2.0 (specifically item 3.1.1 Language of Page). Technique H57 identifies the lang attribute specifically.
Internationalization
The W3C Internationalization (I18n) Activity has a great Q&A on why you should use lang, which was updated less than two months ago. I'll reprint the start of the answer, but there is far more detail and I strongly recommend you go read it.
Identifying the language of your content allows you to automatically do a number of things, from changing the look and behavior of a page, to extracting information, to changing the way that an application works. Some of language applications work at the level of the document as a whole, some work on appropriately labeled document fragments.
We list here a few of the ways that language information is useful at the moment, however, as specifications and browsers evolve in the future there could be numerous additional applications for language information.
Interesting Aside
If you go to the WHATWG HTML5 specification today and view the page source, you'll see the following language declaration in the code:
Not to be outdone, the W3C HTML5 spec has the same language declaration.
If anybody has the en-GB-x-hixie phonologic dictionary in his or her screen reader, I'd love to hear it.
While technically allowed (the -x puts it in the private use sub-tag category), it's bad form:
Private-use subtags do not appear in the subtag registry, and are chosen and maintained by private agreement amongst parties.
Because these subtags are only meaningful within private agreements and cannot be used interoperably across the Web, they should be used with great care, and avoided whenever possible.
<input type="number"> will open a numeric software keyboard on modern mobile operating systems. Not every user can input decimal numbers into this convenient field without proper localization.
[…]
Half the world uses a comma and the other half uses a period as their decimal mark. (In Latin scripts.) Does your web application take that into consideration? Do the browsers?
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.
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.
1. 24 Ways
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.
2. Perl Advent Calendar
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.
3. 24 Jours de Web
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).
4. UXmas
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.
5. Webkrauts
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.
6. Web Accessibility Advent Calendar 2014
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.
7. 24 Pull Requests
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.
8. SysAdvent
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.
9. Lean/Agile Advent Calendar
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.
10. Performance Calendar
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.
11. Free Font Calendar
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.
12. Amazon Web Services Calendar
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.
Not Web Related
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.
Animated GIF showing the tab order on a page using the default Re-CAPTCHA, which sets a tabindex, forcing a keyboard user through six tab-stops to get to the Skip to content link.
Tabindex had the potential to be a useful attribute. A developer could set the order in which focus is moved on a page as a user tabs through the form (or links, or content). It became a stop-gap for forms and pages that relied too heavily on absolute positioning and didn't flow naturally. The problem is that it is often set by developers who don't have any idea of what the user expects.
This mis-use has effectively guaranteed that using tabindex values greater than zero is a bad idea. If, as a developer, you have to use tabindex on a form, then the page itself probably isn't laid out well and will only confuse keyboard users and, more importantly, users of assistive technology.
Browsers take any element with a positive tabindex value and promote it to the front of the pack for tabbing through the page. Only after a browser gets through all elements with a tabindex does it then fall back to source order. It doesn't matter if your tabindex is one million, it will still trump everything on the page that doesn't have a tabindex.
Setting tabindex="-1" allows you to set an element's focus with script, but does not put it in the tab order of the page. This is handy when you need to move focus to something you have updated via script or outside of user action.
tabindex="0"
Setting tabindex="0" will take an element and make it focusable. It doesn't set the element's position in the tab order, it just allows a user to focus the element in the order determined by its location with the DOM.
tabindex="1" (or any value > 0)
Do not set a tabindex="1" or any value greater than zero (or any positive value).
The Example
The example in the animated GIF above is unfortunate in that the site developers themselves don't set a tabindex (I found this at User Experience Impossible: The Line Between Accessibility and Usability on the GSA's DigitalGov site). Instead, for reasons I cannot explain, they use a CAPTCHA on the comment form. The implementation they chose, however, inserts its own tabindex values.
This means that as the user starts tabbing through the page, he or she is first sent to the text entry field on the CAPTCHA in the comments section.
Even as a sighted mouse-user, I was confused how I got there as I tabbed into the page. It takes five more tabs to get to the link that allows the user to skip to the content (which appears first on the page).
This also creates a problem for a user who is filling out the comment form, as tabbing from the Name and then Email fields puts the user on the privacy link for the CAPTCHA, but not into the field where he or she can type the text to submit the form. Some users may never know there is a CAPTCHA there depending on how they got to the comment form.
I don't want to beat up the DigitalGove folks, but this is a great example of how a perfectly functional page (regardless of how I feel about the hover versus focus styles) can be ruined by not testing it after adding third-party widgets.
I discovered while trying to leave a comment that the ReCAPTCHA is served via HTTP while the page is served via HTTPS. One of my browsers (IE) blocks it by default because it's an insecure element on a secure page. That means I won't experience the tabbing problem, but it also means that I cannot leave a comment as the form silently breaks without the ReCAPTCHA. I've left a comment for that as well (but I didn't see a preview and I got no error messages, so, yeah).
Here's the rub — I don't want people beating up the DigitalGov team. That these folks have put forth such a good effort but fallen down on one issue is not uncommon. We all do that. I do it (last week Karl Groves discovered a CAPTCHA on this blog that I never saw). That I found it on a post about accessibility is unfortunate, but it also means the DigitalGov team needs to be more responsive when provided with clear technical solutions and learn to test after each feature addition. Like all the rest of us who work in or near accessibility.
Update: November 19, 2014 at 6:25pm
The comments I posted on the DigitalGov page are still in moderation queue, even though comments posted well after mine have been approved. You can see them still in moderation in the screen capture.
Given my suspicion that they won't be posted (since I've heard nothing back from the initial conversation with the Twitter account), I'll post the comments here. The first was a reply to a site admin following up on a comment from another user noting that the keyboard navigation of the page is broken. My second comment is a follow-up.
The content of my comments is in the page content.
The ReCAPTCHA on this page uses a tabindex value. Since browsers honor tabindex values before falling to source order in the DOM, the very first (through fifth) tab stop on the page is the CAPTCHA. It takes six presses of the tab key to get to the “Skip Navigation” link. That’s the issue I suspect TRUEAXGUY is referencing.
As I’ve said before, I am happy to help, but the easiest fix is to remove ReCAPTCHA or, failing that, go to line 449 of this page (I don’t know where you call it in your pre-rendered code) and remove this: tabindex: 4 (making sure to also remove the comma from the line before it so the JavaScript doesn’t break).
Also, the ReCAPTCHA is blocked by one of my browsers because it’s served as HTTP instead of HTTPS, while the page itself is served as HTTP. This means some users may never even be able to comment (no error messages are displayed on submission, it just silently fails).
Since you have moderation enabled, and since CAPTCHA is already a proven accessibility barrier, and since it’s messing with keyboard navigation, I strongly suggest you remove ReCAPTCHA altogether.
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.
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:
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 was a live stream throughout the day, which was broken into a morning video and afternoon video. I've embedded the morning stream because it includes my talk. I don't feel this was one of my better performances, but I also have not watched the video yet. You are welcome to do so and wince on my behalf. If the embed doesn't start at the right place for you, you can either fast forward to 2:01:00, or you can view it set to start at that point on YouTube.
Surprisingly Flattering Tweets
I'm pleased to sat that if you only watched Twitter, it looks like I did a good job getting my point across.
We pretend that we're helping others by making web #a11y but we are really making it better for our future selves by @aardrian next #a11yTO
I snapped some photos, but I'm going to lead with this awesome sketchnote (I've never had a sketchnote of one of my talks, so this is pretty exciting for me):
Sketchnote from Andrea O Pietkiewicz. View the original tweet or on her site.Sporting an AODA hat & Kirk tie, @DavidLepofsky fits into #a11yTO pretty well.A sneak preview of The Viking & the Lumberjack at #a11yTO. That will never air.Whose responsibility is #a11y? @dboudreau addresses in his talk for #a11yTO.Food-oriented, with reluctant hero, hockey. @karlgroves wins the hand with Strange Brew. @FYCGame
Toronto's Accessible Media Inc (AMI) interviewed me in its coverage of the event, which is now live on the AMI site (season 1, episode 1, as this link will show the current AMI Inside episode not this specific episode over time). The abstract:
AMI Inside provides an all access pass to Accessibility Camp, Toronto. D.J. Demers takes us to OCAD University to learn about some of the most relevant digital accessibility topics. Find out what’s new in technology and hear firsthand from some of the attendees as well as Accessibility Specialist and camp co-organizer, George Zamfir.
The Paciello Group is holding a full day of free webinars on Global Accessibility Awareness Day. That's 24 straight hours of talks, which started at midnight (GMT) on Wednesday, May 20 through through midnight (still GMT) on Thursday, May 21. I was fortunate enough to participate as a speaker and had the third slot in the queue.
For a few years now web developers around the world have celebrated 
