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
Yesterday I presented a stripped-down version of my Selfish Accessibility talk at Buffalo Unconference. With an unknown audience and a 20 minute timeline, I gutted most of the technical bits and focused on my thesis. I think it was well received.
At the end of the talk, I pointed people to the version of this talk I gave for Avega Group last month in Stockholm, as it has (many more) slides (with more detail) and video of me rambling. That longer talk is a bit of a disservice to those who don't want to hear me drone on for an hour and a half as well for those who aren't technical.
With that, here are the slides from yesterday in all their concise glory.
The conference produced just one tweet to satisfy my ego:
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.
Rounding out my European tour (I'll be at Booster in Bergen and ACE! in Krakow) is a speaking gig not at a conference. I've been grabbed by the fine folks at Avega Group to speak to their team in Stockholm on the evening of March 19.
I'll be speaking about accessibility not just to Avega Group, but apparently whomever else might like to attend who is in the area. There is a Google Form you can fill out if you would like to attend (it's after business hours, so it needn't eat into your day too much).
The abstract from my talk:
We can all pretend that we're helping others by making web sites accessible, but we are really making the web better for our future selves. Learn some fundamentals of web accessibility and how it can benefit you (whether future you from aging or you after something else limits your abilities). We'll review simple testing techniques, basic features and enhancements, coming trends, and where to get help. This isn't intended to be a deep dive into ARIA, but more of an overall primer for those who aren't sure where to start nor how it helps them.
More information is on the Google Form, which I have also embedded below:
If you will be in the area, here's a map of Avega Group's venue:
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?
Image showing the pixel-art image of Jeffrey Zeldman in his iconic blue beanie (top left) simulating (clockwise) protanopia, deuteranopia, and tritanopia.
Blue Beanie Day, or for about 0.05% of the population with tritanopia/tritanomaly, Teal Beanie Day!
On Sunday, November 30, web designers and developers across the globe will celebrate Blue Beanie Day 2014, wearing a blue beanie to show their support for web standards. Join in!
[…] [S]porting a blue chapeau is a reminder that web standards—standards like semantic markup, neatly separated styles, and DOM scripting—are responsible for much of the work we do today.
No, I'm not taking a shot at Blue Beanie Day nor the intent behind it. My goal is to remind people that accessibility is core to the standards, and ignoring it is tantamount to ignoring the standards this day is intended to promote.
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.
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:
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 Buffalo WordCamp shirt was again printed by You and Who (whose logo is visible where the tag would be), which means that 1,600 meals were donated (one for each shirt) to those in need. I think every WordCamp should do this. (related tweet)
Buffalo WordCamp has just wrapped up and folks are hopefully going to take new ideas back to their own projects. There were many great talks and even panel discussions that turned into more of a WordPress support group for the audience and panelists alike. A first for Buffalo WordCamp that I hope they repeat. Also a plus, 48% of the attendees and 35% of the speakers were female, better ratios than I've seen at many other conferences.
My Slides
If you just come for my slides, then you are at the right spot. I've embedded them here, or you can go see them at SlideShare. In addition to questions and feedback from the audience, I've already gotten some feedback from the Twitterverse. In particular my use of the word "continuum" on slide 77. I am open to suggestions for a better word, so feel free to share.
Photos
I grabbed some photos from the event as well, captioned below (originally posted on my Tumblr, where they are larger).
This year the event was held in the new Science Hall at Canisius College. This is the atrium where lunch was served and announcements were announced (shot taken shortly after the lunch crush).Some of the announcements being announced by announcers and co-organizers Ben Dunkle and Andy Staple.A nice spread of pastries to get the day going. I am amazed I only ate one.Accessibility talks never net a huge crowd, but at least those who did show up wanted to learn more, had good questions, and challenged me.After a quick Twitter poll, I broke from my normal pattern of wearing more professional attire and went with the Montgomery Ward mechanic's shirt with the fur collar.The badge had the day's schedule printed on the back (handy), and they also provided a printed schedule (also handy).View of the cemetery from one of the talks.A view from the after-party at Western New York Book Arts Center.Some sample type at Western New York Book Arts Center. If you've never been and you are at all interested in type, you should visit.
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.
