Archives

Home » Blog

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

Accessibility Bookmarklets and Tools

This post originally appeared on my blog.

Testing accessibility on your web projects can be a tricky task if you have no firsthand experience with visual, audible, physical or even cognitive impairment. Having resources in the community is important as is tracking down the same tools in use in that community.

Despite all this it’s nice to have some quick techniques for testing your sites without the need to break from your regular workflow. Conveniently, there are a number of tools already out there. Here is a quick rundown…

WCAG 2.0 parsing error bookmarklet

From Steve Faulkner, this experimental bookmarklet uses string matching to evaluate a page against the WCAG 2.0 success criterion for section 4.1.1 Parsing. It leans on the W3C Nu Markup Validator to do its job.

Get the WCAG 2.0 parsing error bookmarklet from The Paciello Group for yourself and while there, read up on how to use it.

Nu Markup Validation Service Bookmarklets

Excuses for failing to use the W3C Nu Markup Validator fall away when all you have to do to validate a page is click on a bookmarklet. Also from Steve Faulkner, this collection of four bookmarklets allows you to validate the current page (in the current window or a new one) or provide the URL of a page to validate (in a new window or not).

Get the four Nu Markup Validation Service bookmarklets (also from The Paciello Group).

Favelets for Checking Web Accessibility

Jim Thatcher has come up with a series of bookmarklets (or as he calls them, favelets) that allow him to make the human review process easier by highlighting details he might otherwise have to wade through code to see. Bookmarklets include image checkers, heading counters, data table notes, ARIA details, and form features.

Get the full collection of “favelets” for checking web accessibility and be sure to read the detailed instructions on how to use these in conjunction with a manual testing process.

Web Accessibility Toolbar

This particular tool is not a collection of bookmarklets. It is also not built to work for any browser other than Internet Explorer. It does, however, provide far more features than bookmarklets can do on their own. Used in conjunction with a manual test and the bookmarklets listed above it can help our overall accessibility testing process far more than just the bookmarklets alone.

Download the Web Accessibility Toolbar For IE and give it a test run on your sites.

If for some reason you are running Opera 8 or Opera 9, there is a version of the Web Accessibility Toolbar for Opera (but again, only 8 or 9).

Juicy Studio Accessibility Toolbar

This toolbar is a Firefox add-on from Gez Lemon. Like the toolbar above, it provides a bit more control than a bookmarklet will afford. This will show you ARIA live regions, show you ARIA landmarks and roles, provides a table inspector and a color contrast analyzer.

You can get the Juicy Studio Accessibility Toolbar from the Mozilla add-on site.

NonVisual Desktop Access (NVDA)

Since I’ve strayed far afield of bookmarklets I thought I would toss this last one into the mix. NonVisual Desktop Access (NVDA) is a free, open-source screen reader for Windows. While it’s intended for the entire OS, it’s also great for testing web pages. Its support of different accents makes for much fun when it speaks to me as a Scotsman.

Download a copy of NVDA for yourself and make sure to donate when you do — this is how projects like this are able to continue and how you can support the disabled community.

Somewhat Related on My Blog

Dining in the Dark

This post originally appeared on my blog on Wednesday, April 25, 2012.


A blindfolded photo attempt of my meal, served and eaten in near darkness. Thankfully it turns out that my aim with my fork was better than my aim with my cellphone camera.

Two weeks ago our longtime client Olmsted Center for Sight (formerly the lengthily-named Elizabeth Pierce Olmsted, M.D. Center for the Visually Impaired) held a benefit dinner titled “Dining in the Dark.” The concept was quite simple and given away by its name — attendees would enjoy a meal in total darkness. Not only did my company co-sponsor the event, I attended it and had the pleasure of dining with Olmsted’s president.

The meal started off with wine and salad, which you were allowed to eat in light. Then we were presented with bibs and blindfolds, and the lighting was turned down to just the candles on the table (the servers needed to see, after all). And so in darkness we set upon the main course followed by the dessert course and wrapped up with coffee service. During the main course an Olmsted representative guided us through techniques to get the lay of the land, identify foods, cut meat, find drinks and so on. I ignored all this and dove in with my characteristic nonchalance about my meal and found myself stymied by the simplest things — it takes a couple tries to realize your knife is upside down and that you are cutting with the blunt edge and not the sharp edge.

I have spent over a decade working with Olmsted Center for Sight. I have had the opportunity to see how its clientele/constituency uses computers and surfs the web. I have attended seminars, spoken at events, been a part of lawmaking discussions, implemented software and web sites, all in my time consulting with Olmsted. I have been working with low-vision and blind users for most of my professional career, but nearly always in the form of technology. Though I had some time running concerts for thousands of attendees and making sure outdoor and non-standard venues were handicapped accessible, this dinner afforded the chance for me to experience some of the day-to-day tasks that I take for granted, but this time without sight.

This post may seem to be a little outside of my generally technical discussions here, but I believe that experiences like this are important for anybody who cares about inclusive design or accessibility. Some day everyone reading this will have reduced vision, mobility, hearing, and so on. Learning now how to design and build to support those changes serves to position future generations of developers to design and build to support the future you. That’s just a good investment in your long term well-being.

Consider spending an hour blindfolded and try to do a mundane task like get dressed, eat a meal, or even use the web to look up a menu on a web site (you’ve already seen me rant about how awful that experience is for average users). Consider limiting your movement, restricting yourself to a chair, putting in earplugs, and so on. You may find your get far more insight into daily life as well as software and web development than you expected.

If you’re still reading and also care about accessibility, then in keeping with the low vision theme of this post here are some resources to use when developing sites for the blind. This is not an exhaustive list by any means, but there are links to many others within.

This handy video shows you how blind people use the iPhone 4S. It’s worth a couple minutes of your time.

This link isn’t a resource, instead it’s a story of a police department using its forensic techniques to help save 26 pages of hand-written content after the blind writer’s pen ran out of ink.