Accessible Bootstrap Frameworks

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).

Assets.CMS.gov

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.

PayPal's Accessibility Plug-in

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.

Related

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.

Update: July 7, 2014

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).

Accessibility Regulation Confusion from U.S. Government

There has been some activity lately from the U.S. federal government related to accessibility requirements for web sites. Unfortunately, that activity is sending a mixed message to many burdened with making a case for accessibility compliance in the private sector.

Good News

The U.S. Department of Justice (DoJ) made news in the accessibility community back in March by issuing a Consent Decree in a case with H&R Block requiring H&R Block to follow the Web Content Accessibility Guidelines (WCAG) 2.0. From the DoJ press release:

On Dec. 11, 2013, the Civil Rights Division and the U.S. Attorney’s Office for the District of Massachusetts filed a complaint in intervention in the lawsuit National Federal [sic] of the Blind (NFB) et al. v. HRB Digital LLC et al. to enforce Title III of the ADA [Americans with Disabilities Act]. […]

[…] The recognized international industry standards for web accessibility, known as the Web Content Accessibility Guidelines (WCAG) 2.0, can be found online and are freely available to help companies ensure that individuals with disabilities can fully and equally enjoy their web-based goods and services.

Under the terms of the five year decree, H&R Block’s website, tax filing utility and mobile apps will conform to the Level AA Success Criteria of the WCAG 2.0. […] H&R Block will also pay $45,000 to the two individual plaintiffs, and a $55,000 civil penalty.

Essentially the DoJ stepped into a lawsuit, identified an accepted standard to follow, and put some teeth in its action in the form of a financial penalty (both in cash and H&R Block's cost to rebuild its offerings). For those who champion accessibility, this is a win.

It's not the first. Back in 2012 the DoJ filed a Statement of Interest in a battle between Netflix (never mind that it's in a PDF) and the National Association of the Deaf that the absence of closed captioning violates the ADA. Earlier this year it also filed a Statement of Interest in a case against Lucky Brand Jeans (another PDF) for its inaccessible customer-facing credit card swipe machines (which probably inhabit far more stores than just Lucky's).

The DoJ has effectively been enforcing ADA laws for private entities, not just state and local governments. This is A Good Thing™

Bad News

Let's ignore the fact that the DoJ can't get the name of the National Federation of the Blind correct in a press release, or that the ADA site provides Statements of Interest from the DoJ as PDF files (you can learn some more about PDF accessibility at Denis Boudreau's a11y Tips site).

The Laws

The DoJ was expected to release a set of legally binding standards for web site accessibility back in April. That deadline flew by with hardly a word from the DoJ. Instead, buried in a Unified Agenda (a catch-all planning document), The DoJ casually mentioned that it's been delayed until March of 2015. You can credit Seyfarth Shaw LLP for catching that one.

As the Law Office of Lainey Feingold notes, this has been happening for years:

The web regulations have been pending since July 26, 2010 when the DOJ issued its Advanced Notice of Proposed Rule Making (ANPRM). The public comment period ended on January 24, 2011. Ever since then, the DOJ has been announcing deadlines for the next step — and then moving those deadlines as the target date approaches.

Enforcement

The H&R Block Consent Decree has some dates associated with adhering to the ruling. One of them (14.d) has come and gone:

14. Web Accessibility Policy [underline theirs, not mine]: By June 1, 2014, H&R Block shall adopt and implement a Web Accessibility Policy consistent with the attachment at Exhibit A and as approved by the Private Plaintiffs and the United States. By June 1, 2014, H&R Block shall: […]
    4. make publicly available and directly link from the www.hrblock.com homepage, a statement of H&R Block’s policy to ensure that persons with disabilities have full and equal enjoyment of the goods, services, facilities, privileges, advantages, and accommodations of H&R Block, through www.hrblock.com, its mobile applications, and its Online Tax Preparation Product; […]

When I visit the H&R Block home page, I see no link or content related to accessibility, disabilities, nor the ADA (if I am wrong, please correct me). I even made an archived version from the Wayback Machine so you can see it in case H&R Block changes it tomorrow (see how you can make your own).

Granted, that requirement is only a week overdue, but given that the DoJ is four years overdue on issuing regulations, one could argue that deadlines don't carry much weight with the DoJ.

Just Setting a Good Example

The DoJ site itself is not exactly a shining beacon of accessibility. From the odd image map on the logo (really, one image, two links to the same location?) to text as images, it could use some help. If you head over to the DoJ Acccessibility Information page you will see it states that the DoJ is committed to provide its content in accordance with Section 508 of the Rehabilitation Act.

If you've been working in web accessibility, then you may be aware of the government web site devoted to Section 508, which requires that Federal agencies’ electronic and information technology is accessible to people with disabilities, and which is intended to be used by federal employees: Section508.gov

As I challenged on Twitter, try using it with your keyboard. Go ahead. Just try it.

For the more technical among my readers, here's an example of the CSS declarations of agony (files linked in this tweet):

WTF? section508•gov CSS: img, a img { border: none; outline: none; } :focus { outline: 0; } http://t.co/EKk1JvkC9D http://t.co/svCNTYifpx

— Adrian Roselli (@aardrian) June 8, 2014

For added fun, find the Skip link and then see where it takes you.

The government body in charge of creating rules for making sites accessible is built based on the requirements of a federal site that itself is a complete cluster. It may, in fact, be a brilliant parody site showing government workers how not to build a compliant site.

Or it might really be the best they can do.

What You Should Do

Keep coding (or start coding) your sites to meet Web Content Accessibility Guidelines 2.0 Level A and AA Success Criteria. This is the requirement the DoJ put in its ruling against H&R Block, the most recent example we have of where the federal government is defining a standard.

And then stop worrying. As WebAIM notes, fear of litigation isn't the best reason to make a site accessible. You should do it because it's the right thing to do. Of course, in my HTML5 Developer Conference talk, I argue that making accessibility all about you (slide 13) is probably a more effective means of getting developers to implement, but I leave that decision up to your personal level of narcissism.

Related

• Assets, the accessible, Bootstrap-based development framework from the federal government (really from the Centers for Medicare & Medicaid Services).

Update: June 9, 2014

Read my post about Assets, the U.S. government framework based on Bootstrap 3, and PayPal's accessibility plug-in, which promises to make your existing Bootstrap implementation accessible: Accessible Bootstrap Frameworks

Update: June 25, 2014

In a release last week from the National Federation of the Blind (NFB), the NFB and a blind business owner reached an agreement with the Small Business Administration because its web site violated Section 508 (read a brief from the law firm representing the NFB). This is newsworthy for two reasons:

• The SBA is a government agency and is being held to the only current federal law pertaining to web site accessibility, effectively stating the government has to follow its own rules.
• The Section508.gov site, the one housing the rules to which the SBA is being held, doesn't follow those very rules, as I noted above.

I am struggling to find a way to describe how absurd this is. I am open to suggestions.

So You Think You’ve Built a Good Infinite Scroll

So you’re saying there’s a chance … that I’ll make it to the footer.

Last week Derek Featherstone posted Automatic infinite scrolling and accessibility, a quick rundown of why having your page just keep going without user input to do so can be such a hassle for users. Also, don’t do it.

In the comments someone trotted out an example of his own automatic infinite scroll that he felt was effective and was developed with the user in mind. I got a bit ranty and suggested otherwise. That wasn’t as productive as it could be, partly because I was commenting on one example that other developers might feel doesn’t apply to their own efforts at similar implementations.

I think maybe this could all be made a bit easier by offering a quick checklist of what to test, expect, and review if you attempt your own version of an automatic infinite scroll. Here is my attempt at one, but please feel free to suggest others (or corrections) in the comments below.

1. Can the user hit “back” and return to the exact same place?

There’s nothing quite so infuriating as loading a few screenfuls of content, following a link, and then coming back only to find you have to reload those screenfuls of content all over again. Not only is it a waste of time, it’s a waste of bandwidth.

2. Is there paging for when the JavaScript breaks?

Everybody surfs without JavaScript while the page is loading, and that load time can be extended by network lag. In addition, broken third-party scripts can take down your own script. Can the user still get past page one if the JavaScript has fallen down?

3. Does the page have a footer?

Now you’re just being a tease. The user will never get there, so don’t lie by showing the footer and implying he or she can get there. You might as well just remove it. It’s at least honest.

4. Can a keyboard user access all other content on the page?

Unless the content that keeps updating is (or contains) the last focus-able element in the source order (the linearized version of your page), then a keyboard user (as well as screen reader users) will never be able to get to that content. Just like the footer you might as well remove it altogether.

5. Can you share a URL to a specific place on the page?

After you’ve gone a few screenfuls deep you may have found a few links of interest. Can you copy the address from the browser and email it (or even tweet it) and expect the recipient will come to exact state of the page (a few screenfuls in and with that content visible in the viewport)? Remember, an anchor is useless if it hasn’t loaded yet (or has been co-opted by your script).

6. Can a user easily jump ahead a few “pages” to quickly get to content much further down the list?

Consider a list of news. After a couple screenfuls you might glean that each screen loads a week (or a month or whatever time period). You want content from a few weeks ago (or a few time periods ago). In a traditional paged navigation you could jump ahead a few screens to more quickly get further down the timeline. If your approach doesn’t afford users this control, you’re wasting your users’ time and bandwidth.

7. Does the memory footprint of the page dramatically increase after just a couple new “pages?”

Keep your favorite memory monitoring tool open and load a few screenfuls. Then a few more. Then perhaps all. Take a look at how much memory this requires and then compare to available memory on other devices (such as smart phones). Remember that a mobile browser may reclaim memory by dumping other resources from working memory, potentially purging the rest of your site and its assets from the user’s cache, resulting in more bandwidth overhead and longer download times on subsequent pages.

8. Is there a way to disable automatic infinite scrolling and lean on standard paging?

Can the user easily disable the infinite scroll? Forget browser configuration acrobatics, instead look for a very visible single-click/tap option for the user to disable infinite scrolling and move on.

9. Have you conducted any user tests?

Before you roll this out, make sure some real users sit down in front of it. Nobody from your organization. Nobody who is an IT professional, developer, or whose paycheck depends on making you or your boss happy.

10. Are you satisfying a use case that has come from research or user request?

Did this feature request come from users, or the client? Or your boss? Or your desire to flex your scripting muscles? If you don’t have a compelling use case or feature request to add it, you may want to put your efforts toward features that truly have value, like print styles.

11. Do you have any analytics/tracking to measure success?

If you do decide to launch your perfect automatic infinite scroll feature, don’t forget to put some tracking scripts in place to determine how many screens deep your users go, and how often they click. There are other things you can measure (like if the footer ever gets clicks on that page). After all, success isn’t measured by you launching, but by whether or not it works well.

Update: July 14, 2014

Remember the example site from my infinite scroll post? Site now does two-screen-at-a-time-only scroll: http://t.co/5bv9ogogd8 That's novel.

— Adrian Roselli (@aardrian) July 14, 2014

Update: November 11, 2014

I left this list as a comment on the SitePoint article The UX of Infinite Scroll: The Good, the Bad, and the Maybe. Mostly because there is no good. There is only bad.

Update: February 13, 2015

Another post that proclaims the benefits of infinite scroll, with nothing at all to back them up: Infinite Scrolling: Pros and Cons It does list some issues, but it's a woefully short list.

HTML5 Developer Conference Slides: Selfish Accessibility

Today I had the pleasure of speaking at the HTML5 Developer Conference in lovely San Francisco. I presented on accessibility and how it relates to you as a current and future user with my presentation Selfish Accessibility. The full abstract:

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.

After submitting a couple drafts, and then some furious last-minute editing as some of the specs I referenced were tweaked a bit, I managed to squeeze out 89 slides in ~50 minutes. The slides are embedded below. There will likely be a video of the talk coming on the official site later, though I think they started the camera late.

Selfish Accessibility: HTML5 Developer Conference 2014 from Adrian

Quick links to two items I referenced in Q&A after my talk:

• Assets is a cross-browser compatible, 508 compliant and responsive framework that can be used to kick-start your web project. From the U.S. government's Centers for Medicare & Medicaid Services, built on top of Bootstrap 2.
• From the W3C Web Accessibility Initiative: Developing a Web Accessibility Business Case for Your Organization.

If you attended, thanks! Whether or not you did, make sure to grab the links throughout as well as on the references slides scattered throughout (though mostly at the end).

Update: August 6, 2014

Good news everybody! The video for my talk was just posted at the HTML5 Developer Conference channel on YouTube. For your convenience, I have also embedded it below.

On Hiding URLs in the Browser

This image is stolen directly from Allen Pike's post because I don't have time yet to make a proper one. It shows the same page URL as seen in the address bars of Firefox 29 and Chrome Canary 36.0.1951.

Two days ago news broke that Chrome was going to modify the address bar in the browser to hide a page's URL. Web developers reacted pretty swiftly saying it's a bad idea. The first one I saw was Allen Pike's Burying the URL, and then a thread on Hacker News.

My first reaction is that this is a terrible idea, for all the points listed.

My second reaction is different.

I'm a web developer. I rely on seeing the URL every day not only as part of my job, but also to consume content and understand its value. I've been championing human-readable URLs for 20+ years and have railed against platforms that don't use them. Non-human-readable URLs are still valuable to me, though probably not the typical user.

Whether I want to hack a URL to remove the tracking nonsense appended by buff.ly-style shorteners, posit the date of a blog post when the author hides publish dates, or make sure I am looking at the development version of a site I am building instead of the staging or production URL (which is hilarious to get wrong while trying to debug an issue), I see a lot of value in URLs.

I realize that many (most?) other users aren't using URLs the way I do. Sure, I have trained my parents to look for certain things in a URL, but for the sites they frequent, which are often news sites with long strings of nonsense in the URL, there isn't much value for them.

So besides web developers, is this really hurting the typical web user? Is our general outcry based on anything other than a variation on "looks great in my browser?"

I posted a tweet this morning that is getting some retweet action, but I'm not sure that people understand that I am framing the issue from my perspective, not the average user's perspective. If anything, it belies how little I want to be family tech support. The tweet:

I don't want URLs hidden. As a dev I always want them. As family tech support, I don't want to have to retrain my parents on copying URLs.

— Adrian Roselli (@aardrian) May 2, 2014

At the same time, Patrick Lauke was on his own tirade about how, as developers, we aren't really typical users. A couple points from the stream:

"but URLs are the basis of the web" great, but should they be exposed raw to end users? do you miss setting frequency and fine-tuning a TV?

— patrick h. lauke (@patrick_h_lauke) May 2, 2014

i argued when browsers hid "http://", "https://", etc from URL bars. now, i couldn't care less as long as same info conveyed differently

— patrick h. lauke (@patrick_h_lauke) May 2, 2014

URLs have been getting masked, obfuscated, or hidden for some time now. My mobile phone hides a URL as soon as I scroll down the page. My browser doesn't show the HTTP protocol unless it's HTTPS. Opera Coast has gone a step further as it appifies the web experience.

Opera Coast has hidden URLs all along (as I note in my review), and while I don't know how that's mattered to typical users, it was enough to make me stop using it. While it is possible to get to the URL within Opera Coast, it's a bit more of a hassle than I like.

In the case of Chrome, it will be one click (which is one more click than I would like) to show the full URL as this video (embedded below) shared by Mark Harwood shows (sorry, only MP4 for now):

If the hidden URLs feature does make it into a coming release of Chrome, we as web developers can simply disable it with a Chrome flag: chrome://flags/#origin-chip-in-omnibox.

At this point, my resistance to the change is that I am a web developer who consumes URLs and that I don't want to have to re-train my parents how to send a link (without using some nonsense "share" button). I'd rather not see URLs go away, but I'm a professional, I can sort it out.

Unrelated

App Links you say? Don't get me started on App Links.

Update: May 4, 2014: Related

Jake Archibald has shared his opinion in his post Improving the URL bar. As is often the case in technical discussions, the comments have a lot of good back and forth.

Jeremy Keith has his own response post, the mispronounced-yet-whittily-named URLy warning.

Remy Sharp offers an alternative to the proposed URL hiding in hist post On Chrome hiding URLs to protect users from phishing. In short, he tries to tackle the stated reason behind Chrome's desire to hide URLs without hiding URLs.

Not really related, but interesting nonetheless is this post, The Secret Messages Inside Chinese URLs. The post is really talking about domain names on their own, but in the context of the page-level URL discussion I think it's novel.

Update: May 6, 2014

Opera 21 has come out, and among its release notes is this nugget on URLs in the address bar:

We now provide an option to make Opera persistently show a page’s complete URL in the address field.

[…]

For more technical users who need to quickly see the entire URL at a glance, go to “Settings | Advanced: Show always full URL in address field” to view all of that “important” information.

In addition, thanks to a re-start of the conversation on Twitter Jake Archibald has found a study that, while not exactly addressing the entire topic, does address it in part: Does Domain Highlighting Help People Identify Phishing Sites? The non-paywalled PDF file was found by Manu Sporny. Some notes:

Our research asks a basic question: how well does domain highlighting work? To answer this, we showed 22 participants 16 web pages typical of those targeted for phishing attacks, where participants had to determine the page’s legitimacy. […] We conclude that domain highlighting, while providing some benefit, cannot be relied upon as the sole method to prevent phishing attacks.

Now to change gears again, for those who claim that browsers have always shown the full URL, I present the following evidence that it's not quite true: Lynx 2.8.1 (one of the browsers I used daily back in the old days, not as a novel testing tool).

A screen shot of Lynx 2.8.1 viewing a page at CNN with no visible URL, as well as no obvious way to display it.

Update: May 13

A couple more interesting reads have popped up. One is a more in-depth and sweeping discussion from Jeremy Keith that builds on his original post and equates the removal of relatively small features with the long-term removal of control from users: Seams

The other one I missed during my first update to this post. Nicholas Zakas argues that URLs are already dead.

We Need to Raise a Stink about Net Neutrality

Found this on the Twitters in @CypherTheDane's tweet. Read a full-text version of this graphic.

In January I wrote about the latest risk to net neutrality here in the U.S (Net Neutrality News). Unsurprisingly, the only change since then is that net neutrality is more at risk, despite some brief outcry and even a million-signature petition.

You should care. We should all care. Remember, it's just a matter of time before that thing you like to do on the Internet is throttled down to painfully slow in favor of that other thing you don't like on the Internet.

Want to play a video game with your friends? Maybe Microsoft is paying to prioritize its XBox traffic over your Sony Playstation. Want to watch Netflix? Good thing Netflix is already paying for priority access and probably passing that cost on soon enough. Want to found an internet business and compete with the likes of Twitter? Ask your funding source to compete with Twitter's pocketbook just to get access.

The thing is, as consumers (which include those of us on our couches and those of us running a business) we cannot afford to stand by and hope this sorts itself out in favor of anyone but the telecommunications industry.

Why We Cannot Hope for the Best

I am loathe to dive directly into politics here. Few people want to hear me rant about my plan for outlawing Crocs and regulating the chocolate industry to require that white chocolate is made with real cocoa butter. However, this is important.

We can look to our president and hope that he is going to stand up for net neutrality. We can even feel good about a promise he made in 2007 when running for office (as reported by Cnet):

I am a strong supporter of Net neutrality. What you've been seeing is some lobbying that says that the servers and the various portals through which you're getting information over the Internet should be able to be gatekeepers and to charge different rates to different Web sites…so you could get much better quality from the Fox News site and you'd be getting rotten service from the mom and pop sites. And that I think destroys one of the best things about the Internet—which is that there is this incredible equality there.

— Presidential candidate, Senator Barack Obama

He seemed to get it. He referenced Fox News, arguably his biggest mass media critic then and now, as someone who could pay for more access. I thought we could count on this guy.

Except President Obama has made other promises that haven't panned out (like every other modern president, of course), including ones that have led to the situation we're in now. Relevant here is his campaign promise to not put lobbyists in his administration, which Politifact rated as broken as early as 2009.

The FCC's current chairman, Tom Wheeler, is an example of that broken promise. Tom Wheeler's FCC bio lists his books and some of his jobs. It fails to note, however, his roles as President of the National Cable Television Association (NCTA) and CEO of the Cellular Telecommunications & Internet Association (CTIA) (1992-2004), both lobbying organizations.

It's easy to make the case that his nomination to the FCC post is a function of his campaign donations. For Obama's first run at the presidency, Wheeler raised between $200,000 and $500,000 and personally gave $28,500 to the Obama Victory Fund. For Obama's re-election campaign he hosted a $5,000 to $20,000 per plate fundraising lunch.

To recap, the guy in charge of making the decision over net neutrality is a former lobbyist for the very industry that wants to prevent net neutrality. He likely got this job as a function of his financial support for getting his future boss elected. It seems unlikely net neutrality will find a friend in either Tom Wheeler or President Obama.

Realizing that this is the kind decision that the FCC and White House might be motivated to make quietly, someone took the time to start a petition on WhiteHouse.gov (the ideal armchair activist site). The idea here is that once (if) it hits 100,000 signatures, the White House (President Obama, but likely his proxy) will have to respond.

If the White House truly complied with its own rules about honoring 100,000 signatures with a response, then we might have gotten a non-answer (though I hoped for a deportation) on the Justin Bieber petition. Ok, that one is clearly a tongue-in-cheek (not really) petition, but others have been ignored altogether, resulting in a petition to get petitions answered (a similar one from 2011 didn't get a response even after it met the then-25,000 signature limit).

Sadly, the FCC is making its own decision on or shortly after May 15. The petition closes 9 days later, so there is no way the White House will be issuing a response before the FCC is already off to the races.

Maybe you can find help via Congress, although you'll probably not get it from the likes of people like Lamar Smith or others who demonstrated a fundamental misunderstanding of the internet with regard to SOPA and PIPA (or demonstrated that they were easily bought by special interest).

What To Do?

Sign the petition. Ideally it will hit 100,000 signatures before its close date and before the FCC's May 15 date. Just maybe the FCC will listen before it goes and breaks the internet for Americans.

The FCC has set up an email address, openinternet@fcc.gov, to solicit comments from the general public. Use it.

Maybe write a blog post, or a news article, or something visible to the general public to help add to the public discontent.

Then express your displeasure, repeatedly, by tweeting, calling, emailing, and so on, the White House, the President, your representatives, the FCC, and for good measure perhaps the first lady, the press, and the (sadly, now deceased) emperor of San Francisco.

Here, I've started a couple tweets for you:

.@BarackObama Honor your campaign promise to maintain net neutrality. (Tweet it)

.@TomWheelerFCC @FCC Guarantee all Americans have access to the internet and our own government by maintaining and codifying net neutrality. (Tweet it)

Related

• FCC to Propose New 'Net Neutrality' Rules
• Creating a Two-Speed Internet
• Former Comcast and Verizon Attorneys Now Manage the FCC and Are About to Kill the Internet
• U.S. Struggles to Keep Pace in Delivering Broadband Service

Update: May 2, 2014

Bill Stewart has written an excellent post that attempts to explain to those who are less technical than the average developer why net neutrality is important. Go read it and share it: Explaining Why Net Neutrality is Important

Update: May 13, 2014

If you're still a bit confused on net neutrality and have 11 minutes to spare for a primer, take this one for a spin:

Update: June 7, 2014

On Last Week Tonight with John Oliver, he takes just over 13 minutes to explain, justify, and then instruct how to defend net neutrality. I have embedded the video below, but for those who just want to act, he points out that the FCC has decided to take comments from the public, which you can do at: fcc.gov/comments, or specifically proceeding 14-28.

As of this writing, there are 49,206 comments, only the most recent 10,000 of which (for reasons unknown) can be viewed (oddly, with addresses) in PDF format (which I cannot explain) at http://apps.fcc.gov/ecfs/comment_search/execute?proceeding=14-28

If you still aren't sure why you should take the time to do this, I present John Oliver's argument:

Update: August 30, 2014

I stumbled across this piece that, while a little late to the party, lists examples of where phone and cable companies have already been violating any prior agreements or statements to honor any kind of unofficial net neutrality: Net Blocking: A Problem in Need of a Solution

Update: November 10, 2014

President Obama appears to have finally remembered the promise he made while running in 2007. Having waited until the last minute, ignored petitions, ignored general calls from industry, he has finally outlined some high-level guidelines and asked the FCC to maybe consider them (I left the tt elements in place in the citation below, though I don't know they are there):

• No blocking. If a consumer requests access to a website or service, and the content is legal, your ISP should not be permitted to block it. That way, every player — not just those commercially affiliated with an ISP — gets a fair shot at your business.
• No throttling. Nor should ISPs be able to intentionally slow down some content or speed up others — through a process often called “throttling” — based on the type of service or your ISP’s preferences.
• Increased transparency. The connection between consumers and ISPs — the so-called “last mile” — is not the only place some sites might get special treatment. So, I am also asking the FCC to make full use of the transparency authorities the court recently upheld, and if necessary to apply net neutrality rules to points of interconnection between the ISP and the rest of the Internet.
• No paid prioritization. Simply put: No service should be stuck in a “slow lane” because it does not pay a fee. That kind of gatekeeping would undermine the level playing field essential to the Internet’s growth. So, as I have before, I am asking for an explicit ban on paid prioritization and any other restriction that has a similar effect.

Despite this positive statement, I think this quote is more telling (subject-verb agreement issues notwithstanding): The FCC is an independent agency, and ultimately this decision is theirs alone.

In short, he's doing nothing.

Patents versus Accessibility

Just one example of the many gesture patents rolling around in the USPTO database, this one for denoting something important by making a heart shape over it.

I haven't ranted about patents for a while, which doesn't mean there hasn't been any activity. In fact, there has been activity in precisely the space where I think patents can disproportionately hurt users — in accessibility technologies.

A couple weeks back Don Norman put together an overview of gestures as user interface behaviors in Gestural Control: The Good, the Bad, and the Ugly. His opening salvo sums up the concern with patent encumbrance:

I await the day when gestures become standardized. When systems combine the best of all worlds: gestures, voice, and menus, keyboards, and pointing devices. But before we can do this, we have a simple task to do: reform the patent system.

He rightly notes that while gestures can be powerful, they are not universal. Cultural differences alone can make gestures difficult to translate across users. Implementation of gestures is also inconsistent, even across devices from one manufacturer (looking at you, Apple, Microsoft, and everyone else). He does identify a scenario where gestures can be consistent:

Yes, some groups of people such as athletes and referees, military squads and others learn standard gestures to let them work efficiently where other means of communication are not possible, either because of the need to be silent or because of a high noise level.

I argue that this statement also applies to users with disabilities. For example, sign language is a common set of gestures that allows its users to communicate regardless of the ability to hear (whether by audio impairment or, as in the case of some of my friends, stealthily complaining about the server).

Patents on gestures is nothing new. The opening example of a heart-shaped gesture to allow Google Glass users to "like" things they see in real life dates back to 2011. That is from a very quick search in the US Patent & Trademark Office (USPTO) database for "gesture." If had a budget to search, I suspect I could find older.

The problem here is that gestures are already obtuse and complex enough in many cases, but patent-encumbered gestures will result in even more unintuitive and bizarre contortions to perform the same function across devices. This will also make it that much harder for users to switch platforms, let alone learn a first platform.

Think about this in the scope of accessibility. As I mused on Twitter, wouldn't it be nice if a user could enable and use accessibility features on any device with the same gesture (or set of gestures)? Just as I can pick up any device and read words on the screen in a generally consistent way, or just as I can expect a ramp to work that same way no matter the building to which it's attached, I think consistency removes a barrier to entry that is otherwise being built up more and more.

Example of a GUI with accessibility features in an Apple patent.

If you think accessibility features will be somehow immune to the patent process, consider Apple's patent for a graphical user interface for the visually impaired (there's a PDF of the entire application as well).

That Apple patent likely means if Samsung wants to use an interface that has even a passing resemblance to the one Apple has patented, you can expect Apple to sue. The same goes for a gesture. The same will go for gestures that are tied to accessibility features.

We've already got a patent system that's out of control, with even the most basic ideas receiving patents. It seems the same patent process is also building barriers to accessibility using the very ideals that should be using to tear barriers down. Ideally with enough people raising a stink we can slow or even stop the process.

Previous Patent Rants

• Frivolous Patents on the Web
• WebM, H.264 Debate Still Going
• More Frivolous Patents
• A Patent Trolling Primer
• Are Patents Killing HTML5 Video?