Archives

Home » Blog

Update to Verizon Using Disabilities to Fight Net Neutrality

In June I discussed rumors that Verizon was arguing, behind closed doors, that net neutrality harms those with disabilities.

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

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

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

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

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

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

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

Hopefully these two are among the comments that will work their way to the top of the pile of the 1.1 million of comments the FCC has received (good luck finding them on your own). And then hopefully they’ll be read, and understood, as the FCC weighs the information in making a decision on net neutrality.

Changing YouTube Playback Speed

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

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

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

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

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

Verizon Using Disabilities to Fight Net Neutrality

This post originally appeared on my blog.

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

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

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

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

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

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

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

Related

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

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

Keep the Focus Outline

This post originally appeared on my blog.

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

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

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

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

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

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

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

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

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

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

Further Reading

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

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

Related

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

My Efforts to Reach Virgin America (so far)

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

Update: June 27, 2014

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

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

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

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

Accessibility Regulation Confusion from U.S. Government

This post originally appeared on my blog.


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:

  1. 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: […]
    1. 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):

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

Accessible Bootstrap Frameworks

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

Screen shot of 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

Screen shot of PayPal Bootstrap accessibility plug-in on GitHub.
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).

HTML5 Developer Conference Slides: Selfish Accessibility

Note: This originally appeared on my blog shortly after the talk on May 22.

2014 HTML5 Developer Conference

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.

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

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.

Free Getty Images?

Screen shot of the Getty embed tool.
Earlier this year, there was big news for bloggers and content authors when Getty announced it would open up ~40 million of its images for free for use on web sites. Over on my personal blog I talked about some things to consider before using those free Getty images on your site.

The Caveats

Since then I’ve had a few of my clients ask me about how and if they can use those images on their sites and blogs, and my blog post is a bit long-winded (it’s written more for technical people). I’ll distill my feedback here, with less technical jargon.

Resizing

If you want to resize the image to fit your layout, you’ll need to know some HTML. Complicating matters, if you have a responsive site that shifts its layout for phones and tablets you’ll quickly find the Getty image doesn’t do the same. What may look great on your desktop could break your layout when you view the same page on your smartphone.

Privacy

You aren’t allowed to place an image right on your pages, you have to reference the image from Getty’s servers using code Getty gives you. While today not much may be in that code to concern you, in time Getty can add anything it likes, including ads.

Longevity

At any time Getty can revoke its license for use (or the photographer could). Because you are using code from Getty, you may never know if the image disappears, potentially leaving a big empty block in your page. To be fair, you take this same risk when you embed a YouTube video, among other services that allow you to use their content or media player.

Code

You need to have access to the raw HTML code of the page in order to use Getty’s code. For some authors and some platforms, this may be a little trickier than it seems. In addition, Getty offers a tool to generate that code, but doesn’t give you any way to customize it. It also doesn’t offer alternate versions of the code (shortcodes for WordPress, for example).

Featured

Many content management systems or blog platforms allow you to identify a featured image for a page or post (such as WordPress), otherwise the platform may use the first image in the page as the featured image (such as Blogger). When you use Getty’s code, there is no image, just a reference to one. Therefore you cannot set it as the featured image and it won’t appear in your blog index or in your RSS feeds.

Accessibility

Getty doesn’t account for accessibility. If your site needs to meet internal or government accessibility standards (specifically for marking up images), the code that Getty provides will certainly fail. Even if you know HTML, you cannot just add the necessary code since you cannot access the discrete image code that Getty ultimately embeds on your page.

One Workaround

Of all the issues I identified above, I can only control one — making the image work in a responsive layout. I have a much more detailed explanation of this over at my blog.

My approach doesn’t require you to modify the Getty code at all. As long as you can paste the following JavaScript into the site’s footer (somewhere before the closing body tag), it should just work when the page loads. To make it work when users resize their windows or rotate their screens, you will need to call the function then as well, perhaps in an onload event in the body.


function responsiveGetty() {

  try {
    // Get all the iframes on the page.
    var iframes = document.getElementsByTagName('iframe');

    // Height in pixels of the Getty credits/share bar at the time of this writing.
    var crHeight = 69;

    for(var i = 0; i < iframes.length; ++i) {

      // Check to see if it's a Getty embed using the only attribute that's unique, the src.
      if(iframes[i].src.indexOf("//embed.gettyimages.com") != -1) {

        eachIframe = iframes[i];

        // Get the current ratio after excluding the credit bar.
        picHeight = eachIframe.height - crHeight;
        picRatio =  picHeight / eachIframe.width;

        // Set the iframe to fill the container width.
        eachIframe.style.width = "100%";

        // Set the iframe height to correspond to the ratio, adding back the credit bar height.
        eachIframe.style.height = ((picRatio * eachIframe.offsetWidth) + crHeight) + "px";
      }
    }
  } catch(e) {}
}

responsiveGetty();

Obviously there are a few ways to implement this, so feel free to play around with it to get a solution that works for you. You can see an example page I made with a few different sizes of images that also resizes them if you resize your window or rotate your device.

Speaking on Accessibility at 2014 HTML5 Developer Conference

2014 HTML5 Developer Conference

I will have the pleasure of speaking at the 2014 HTML5 Developer Conference in San Francisco, taking place May 19 through May 23 (I’ll be speaking on May 22). The quick overview of the conference:

The HTML5 Developer Conference has grown to become the highest attended HTML5, JavaScript, and Web Development conference in the world. Providing tracks on Javascript, HTML5, Apps and Games, client, server, and mobile. HTML5DevConf boasts renowned speakers and leading edge sessions at the most developer friendly price on the planet.

You can learn more at the HTML5 Developer Conference site and you can also follow the conference on Twitter.

I will be speaking about 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.

My bio and the abstract are on my speaker page on the HTML5 Developer Conference site.

Page-Level Container Discussion for HTML5

This post originally appeared on my blog.

HTML5 logo — I am the 'alt,' not the 'title' As I started down the path of my first HTML5 web page I spent a good deal of time trying to understand the sectioning elements of HTML5 — nav, article, aside, and section — as well as the major structural elements such as header and footer.

Trying to find the container to wrap the content of my page turned out to be the hardest part of the process.

Are We Talking about a Content Element?

Some elements more obvious in their intended use than others, but I felt that there was no specific element to denote the main content of the page. I struggled with trying to figure out whether my content should be in an article, a section, or even just a div.

Apparently I am not alone. Even folks on the WHATWG mailing list were asking the same question. And then I saw this feedback from Hixie:

The element that contains “a website or a blog entry’s main content” is
body, as far as I can tell.

It seemed like that was the end of that. Clearly he had considered it and felt that there was no issue.

But in the past week on both the WHATWG mailing list and the W3C HTML Working Group list this topic has resurfaced. And there are some good arguments in its favor.

Why Should We Get a Content Element?

One argument is that developers are already coding a solution to this, often by specifying a div with an ID of “main” or “content.” In this scenario, the concept of paving the cowpath, where HTML5 is intended to reflect how developers actually code web pages, comes into play. If it’s already appearing in code, perhaps formalizing it can allow for consistency in structure and semantics. This is, after all, how we got nav, aside, and others.

Another argument centers around ARIA use for accessibility. Since elements like header and footer have built in ARIA roles, developers who care about accessibility want an element with a similar built in role for the main content. Currently, these developers put role="main" into the div or other element that wraps their page.

The argument in favor of a content / main / maincontent element is then a matter of demonstrating an existing pattern and an end-user benefit, in this case in the form of accessibility.

Why Shouldn’t We Get a Content Element?

The flip side of this argument is that we’re just creating another element to add to the tag-soup that developers are already contending with in HTML5. Evidence today shows us that 95% of the pages that use ARIA ultimately use role="main" properly. Those pages that use ARIA at all only make up 1.3% of a 10,000 page poll, however.

Those users who understand and want to provide accessibility are already doing it with ARIA. Adding a new element may help get more developers to accidentally support accessibility, or it may confuse the issue if its use isn’t restricted to one instance per page.

What Might This Content Element Look Like?

Steve Faulkner proposed a new element, maincontent, on the W3C HTML Working Group list yesterday, pointing to his own draft to start discussions. Ostensibly he concatenated the commonly used IDs of “main” and “content” that already exist in the wild when naming this element.

Where it goes from here is anybody’s guess. Discussion is happening on both lists, but with all the other activity and the push to start to wrap up the specification it may get pushed out. Perhaps this time next year there will be a solid proposal with well-formed arguments on both sides, but I wouldn’t expect to see a new element by then.

Related