Web developer, writer, speaker. Co-founder of his company Algonquin Studios as well as evolt.org. Has co-written “Usability: The Site Speaks for Itself,” “Web Graphics for Non-Designers,” and “Web Professional's Handbook.”
The world wide web has officially lasted 25 consecutive years, which means it's catching up to its parent, the Internet, which itself is bearing down on 45. That's an important distinction. The Internet is not the web, it is the foundation on which the web was born.
In honor of the web's quarter century bringing us all manner of useful and useless information via the lowly hyperlink, the World Wide Web Consortium (the standards body behind HTML and CSS, among other standards) and the World Wide Web Foundation have teamed up to create the site webat25.org.
For good measure, I've included Tim Berners'Lee's video talking a bit about where the web will continue to go:
If you want to pretend that you are enjoying the early days of the web again, head on over to the evolt.org browser archive, which I started building in 1994 (two years after my first foray onto the web), to download the earliest releases of Netscape Navigator or browsers you've never heard of. You can also wander over to the W3C Web History Community Group, where some folks have started to gather early documents.
There was quite a lot of chatter this week over Getty's move to make its image library (ok, only 40 million of its images) free for non-commercial use on the web. Some might think they can now just start taking images from the Getty site, but not quite. Getty requires you use its embed tool.
Caveats
If you're reading this blog, odds are that you are comfortable with HTML. While I cannot deny the value of being able to drop quality images into your site with hardly any effort, there are things as site builders that you need to know so you can best deploy them — or decide if it's even worth using the Getty images.
Accessibility
Because the image is embedded via an iframe, there is no opportunity for you to insert a text alternative, short of using ARIA (such as an aria-describedby attribute). In addition, the img element within the iframe has no alt attribute.
This feels like a miss to me because Getty has the image description — it's part of how search results are generated. For example, on this image page within Getty there is a caption: View from Giotto's Bell Tower (Campanile di Giotto) on the dome of Florence.
For some reason Getty doesn't make this available as a text alternative. I'm not expecting a longdesc here, but the text alternative seems like low-hanging fruit to me.
All of this ignores any possible issues AT might have with embedded iframes. In that case, I'll have to defer to an AT user who has some experience with navigating into and out of an iframe within a page of content. My guess is that it isn't much different from other embedding techniques, such as YouTube or SlideShare.
Web Beacons
In the example at the start of this post you can see there is a Twitter icon and a Tumblr icon. The Twitter button is loaded via (yet another) iframe. Calls are made to both Twitter's and Tumblr's servers.
Every time you embed an image, not only are your users making a call for the image itself, but also calls to Twitter and Tumblr. Getty is probably more than happy to have these tracking beacons in place. While there are only two today, it is not unreasonable to expect to see more social platform buttons and additional beacons appear.
Conveniently, running a blocker like Ghostery won't block the image just because you block the share buttons.
Keep in mind, though, that Getty has full control over what appears in that iframe. While two share buttons may be innocuous today, it is possible (however unlikely) that Getty could choose to start serving advertisements in those iframes.
Depending on our paranoia level for your own content presentation or the paranoia level you presume from your users, this may be an issue. It may also not matter in the slightest.
Link Rot
Once you embed the image and walk away, you have no control. If Getty changes its licensing, if the photo owner rescinds his/her licensing to Getty, if Getty decides to throttle its service in the case of great demand, and so on, your site may end up with a big blank hole. Or perhaps an ugly 404.
I have blog posts that go back to 1999. Services I might have used then to embed content would likely be gone now. Services I have used in just the last few years have gone away. A List Apart has had to make some efforts to combat the risk of link rot when deciding to use embeds on its site. You may want to consider if you or your clients/authors are technically savvy enough or have the time to account for that eventuality.
If you embed YouTube videos, you are already taking a risk with link rot. YouTube, I would argue, has more staying power than Getty's service. I could be wrong, but Getty is just getting its feet wet and finding its way with this service.
Getty's Embed Tool
The Getty image embed dialog just gives you the HTML, no features to adjust the size for those who don't know HTML.
Today there is a simple tool to provide the code for embedding on your site. At the time of this writing, there is no option to generate a shortcode for WordPress or similar sites. This may not be an issue, but it's worth noting in case you have an editor configuration that requires one.
If you manage to find the perfect photo after navigating screen-fuls of images, make sure you either control-click or right-click-new-window the learn more or terms links, otherwise you'll lose your place when the page reloads. That happened to me once for each before I learned my lesson.
Resizing
You'll note in the dialog box that there is no way to control the size of the image unless you know HTML and can do some quick math to maintain the aspect ratio. Even then, the addition of the photo credit and share buttons throws off just a quick resize since the bar doesn't scale at the same ratio as the image.
The image at the start of this post uses the default embed code, which relies on an iframe to get the job done. Here is the code used above so you can see it for yourself:
If I want to make the image fill the width of this column (540px), then I need to scale it up a bit, which gets me extra space below the bar that I don't need:
Scaling it down to 200 pixels in width and maintaining the aspect ratio gets me a minimum iframe height despite my code in order to preserve the now truncated credit bar:
No matter what size you embed the image, the file will always be the same dimensions. Embedding the file smaller doesn't result in a smaller payload delivered to the browser. The image dimensions don't change, so scaling the image up also doesn't give you a higher quality image, just a potentially blurry image.
This is important to consider if you want to make the iframe responsive. You don't get a larger image or a higher quality image as the iframe scales. The image itself isn't high resolution, so scaling up at all will get muddy on high PPI devices.
Alternatives
You can continue to use no images. You could steal images from the web (which is wrong, so don't do that). You can, of course, always find free stock imagery. It typically sucks. However, there is a list of resources over at Medium of stock photography that doesn't suck. You can also look at the CC-BY licensing terms at Flickr and pull images from there (with no troublesome embed).
Alternatively, you can go take the photo you need. Granted, if Getty is appealing to you it may very well be because you don't have the time, skill, or inclination to shoot, edit and embed your own images. There is nothing wrong with that.
However, using your own images gives you many benefits. The image below is mine. I think it looks better than the Getty image I use at the start of this post (which is rarely the case). It is responsive. It is high resolution. It utilizes accessibility features. It has no web beacons. It's a smaller file (42.1KB at 1,000 × 664 versus the Getty image at 91.9KB at 478 × 359).
It also required far more effort to optimize and embed.
Example of my own photo that scales, is high-DPI, and contains basic accessibility features.
Electronic Frontier Foundation has weighed in: Getty Images Allows Free Embedding, but at What Cost to Privacy? It goes deeper into my concerns about privacy and tracking and notes that by not serving the images via HTTPS users may be exposing their surfing behavior even when using a site over HTTPS.
Update: March 16, 2014
I addressed one of my caveats above, the only one over which I have any control and by no means the most important one. I wrote a script to Make Getty Embeds Responsive. Maybe it will help you, maybe you come up with a better variation. Either way, at least you won't have to worry about clients embedding fixed-width Getty iframes that blow up your responsive layouts.
The latest WebAIM screen reader survey results came out last week, and I had been looking forward to the results of the questions related to screen reader detection. I can say I was a bit surprised by both. To make it easy, I'll reprint the questions and answers here.
The vast majority (78.4%) of screen reader users are very or somewhat comfortable with allowing screen reader detection. 55.4% of those with disabilities indicated they were very comfortable with screen reader detection compared to 31.4% of respondents without disabilities.
Screen Reader Detection for Better Accessibility
How comfortable would you be with allowing web sites to detect whether you are using a screen reader if doing so resulted in a more accessible experience? (See the question on the WebAIM site.)
86.5% of respondents were very or somewhat comfortable with allowing screen reader detection if it resulted in better accessibility. Historically, there has generally been resistance to web technologies that would detect assistive technologies - primarily due to privacy concerns and fear of discrimination. These responses clearly indicate that the vast majority of users are comfortable with revealing their usage of assistive technologies, especially if it results in a more accessible experience.
My Opinion
I think the wrong question is being asked on the survey.
Detecting a screen reader is akin to detecting a browser. If you've been doing this long enough, you know that on the whole browser detection is a bad idea. It is often wrong and doesn't necessarily equate to what features really exist, which is why feature detection evolved as a best practice. You can read my rant from 2011 where web devs were making the same mistake trying to detect mobile devices.
Detecting the features of a screen reader is different, however. Here you may be able to actually get somewhere. But this is where different risks come in. I'll focus on three that come to mind immediately.
Double Effort
The first is what happens once you have detected a user with a screen reader. Do you detect for other accessibility tools or ignore those? Do you serve different content? Different mark-up? Do users get shunted to different URLs?
Evidence suggests this doesn't ever go well. Even today, the example of the UK Home Office Cyber Streetwise site is perfect example — the user is provided a link that cannot be activated sans mouse which in turn points to a text-only version of the site. It is not truly accessible and assumes only visual disabilities.
Any organization charged with maintaining two sites will ultimately fail at doing so as resources are prioritized to targeting the primary site. Eventually you get an atrophied site in the best case, and a complete failure in the worst case.
It opens the door to separate-but-equal thinking. Patrick Lauke captured this idea nicely on Twitter, which I re-tweeted with this longdesc (because I am that guy):
A second risk with this detection approach is that selection bias will taint your perspective (I've written about this before). Just as web devs would build features that blocked, say IE6, and then turn around to point out that IE6 usage had dropped on their sites, we can expect to see the same thing happen here.
Poorly-written detection scripts will set the expectation that site owners are getting a view of who is using their site, but will end up showing the opposite. Not only that, low numbers can be used to justify not supporting those users, especially if those numbers come in below the IE6 or IE8 or whatever-is-the-current-most-hated-IE numbers that you've been arguing are too low to support. Roger Johansson sums it up nicely:
@mattmay@jared_w_smith It would likely be used to say "we've only had one SR using visitor the last month, so let's not bother".
We already know that assorted web beacons can cross-reference your social media profiles to your gender to your geographic location to your age to your shoe size. There is already plenty of personally-identifiable information about you available to every site, is it right to allow those sites to know you have a disability?
This is the kind of information that in the United States you might think is covered by HIPAA, only to find that as a general web surfer you are handing it over to anyone who asks. Certainly no registry can be trusted with managing that when even the UK's NHS uploads not-really-anonymized patient data to the cloud (Google servers outside the UK in this case).
Consider also what happens when the site has a different URL for every page targeted specifically at disabled users. Now when those users share a URL to a page, they are in effect telling the world they have a disability, even if which disability isn't clear.
There is a privacy risk here that I don't think those who took the survey were in a position to consider, and I don't those who asked the question were able to contextualize appropriately.
Other Responses
Marco Zehe jumps on this pretty quickly with his post Why screen reader detection on the web is a bad thing. In addition to raising points why he thinks this is bad, he points out where the survey takers might not understand the scope of the question:
Funny enough, the question about plain text alternatives was answered with “seldom or never” by almost 30% of respondents, so the desire to use such sites in general is much lower than the two screen reader detection questions might suggest. So I again submit that only the lack of proper context made so many people answer those questions differently than the one about plain text alternatives.
Léonie Watson also responded quickly in her post Thoughts on screen reader detection with her own reasons that I am breaking down into a bullet list here (on her post, these are the headings for copy with more detail):
I don’t want to share personal information with websites I visit
I don’t want to be relegated to a ghetto
I don’t want design decisions to be based on the wrong thing
I don’t want old mistakes to be repeated
I don’t want things to be hard work
I do want much more conversation about screen reader detection
Text-only websites didn’t work before and you know devs will do this if a mechanism is provided.
Screen reader detection is eerily similar to the browser-sniffing technique which has proven to be a poor practice.
Maintaining separate channels of code is a nightmare; developers overloaded already with supporting multiple browsers, devices, etc (via RWD). And if done, it will many times become outdated if not entirely forgotten about.
Why screen reader detection? If you follow that logic, then detection should be provided for screen magnifiers, braille output devices, onscreen keyboards, voice-recognition, etc. That’s just crazy.
Dylan Barrell is (so far as I have found) the sole voice saying maybe this isn't so bad, in hist post Assistive Technology Detection: It can be done right. He argues for some benefits and then proposes a couple possible approaches to deal with the concerns he is hearing:
Allow the web site to request the information, and the user to allow/disallow this on a per-website/domain basis. I.e. the web site requests and the user decides. […]
A second approach is to put the control in the hands of a registry. This registry would store the domain names of the organizations who have signed a contract that explicitly binds them into a code of conduct regarding the use of the data. […]
Along the lines of separate-but-equal text-only sites being anything but equal, Safeway appears to have bought into that concept and is eliminating its text-only site in favor of making the overall site more accessible.
Update: March 19, 2014
In the post Am I Vision Impaired? Who Wants to Know? the author points out that by installing apps on your phone, you are already giving the app makers access to whether or not you use AT. There is an API for this information and its use is not indicated to end users that way the phone tells/asks you about access to your camera or GPS.
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.
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.
I was recently asked by a client whether or not the cookie law will apply to its overseas business. As a reference, he provided a link to the Computer Weekly article “How to comply with the EU cookie law.”
It's a handy article, but as with most reference material on the web there is no date on the article to give an indication how recent it is. Rules have changed a bit since the law was passed and so the requirements aren't quite so clear anymore.
It is still a regulation, though watered down. Instead of asking explicit permission, you can now get by under implied consent by linking to a cookie policy page from every page on your site. The content of that policy page is still informed by the law. More information on implied consent is available in this PDF.
Enforcement is a different story. My understanding is that enforcement is arbitrary and based on end-user complaints, at which point I think a slap on the wrist and request to make the cookie policy link more prominent may be all that is demanded (I haven't found any verified examples yet).
Obviously I am not an EU citizen nor an expert in international law, but I think you'll find feedback from appropriate counsel would be similar (though probably a bit more risk averse).
For more detail, you can read up on current language of the law at the ICO page (the folks who came up with the law) which includes this clarifying content (dated January 31, 2013):
We first introduced a notice about cookies in May 2011, and at that time we chose to ask for explicit consent for cookies. We felt this was appropriate at the time, considering that many people didn’t know much about cookies and what they were used for. We also considered that asking for explicit consent would help raise awareness about cookies, both for users and website owners. Since then, many more people are aware of cookies — both because of what we’ve been doing, and other websites taking their own steps to comply. We now consider it’s appropriate for us to rely on a responsible implementation of implied consent, as indeed have many other websites.
You may have read my rant earlier this week about Network Solutions trying to trick me into allowing them to send me spam. As part of that dark pattern, Network Solutions asks me to verify my contact information, and then tries to up-sell me, and then suggests that I need to verify my contact information (but which is really a spam opt-in).
You can imagine I am primed against being asked to confirm my information by Network Solutions.
For a little extra context, since I receive a few emails a week from Network Solutions (such as this one to auto-renew, or this one for SEO, or this one to obfuscate my WHOIS info), which jumps to daily after I partake in any activity on the Network Solutions site, I typically filter them into dev/null/i-mean-it.
So I was wary when I received the following email once yesterday (the day after I renewed my domain) and once again today:
I block Outlook from downloading embedded images to prevent spammers tracking when I have opened their emails, hence the missing images.
The message within:
Dear Customer,
New Regulations now require that domain account holders confirm their email information otherwise their domain will be deactivated. If your domain is deactivated you will still own the domain but you will not be able to have a live website until you verify your contact information.
To ensure your domain(s) remain active, please click the CONFIRM button below to confirm the email address we have for you is accurate.
Note the explicit threat. Note the lack of a link to the new regulations, let alone the source of those regulations. Note the shiny red all-caps CONFIRM.
I know this is anecdotal, but it's a great image to make my point.
Because I am a child of the internet age, and because the support phone number in the email could point to anyone, I contacted Network Solutions on Twitter to see if this was for real:
Reassured the phone number in the email is a true Network Solutions number, I called and navigated the menu system. After I explained the situation and why I don't want to click the link, the representative explained that my domain will be shut down if I don't do it. He could not offer a time frame (but he hadn't seen anyone shut down because no one has waited more than two weeks). He also said he cannot do this over the phone and that I must click the link.
When I pressed for the regulation, he said it's an ICANN regulation but could not tell me where to find it. He explained that if I don't respond, eventually my domain will point to a parked page (my word), though he didn't know if it's an advertisement-laden Network Solutions page or an ICANN page.
When I got off the phone, I looked around for an ICANN regulation. The closest thing I found was in a PDF dated June 27, 2013 (page 43, under WHOIS Accuracy Program Specification):
Registrar shall implement and comply with the requirements set forth in this Specification […]
[…] within fifteen (15) days of (1) the
registration of a Registered Name sponsored by Registrar, (2) the transfer of the
sponsorship of a Registered Name to Registrar, or (3) any change in the Registered
Name Holder […]
Verify:
the email address of the Registered Name Holder (and, if different, the
Account Holder) by sending an email requiring an affirmative response
through a tool-based authentication method such as providing a unique
code that must be returned in a manner designated by the Registrar, or
the telephone number of the Registered Name Holder […]
In either case, if Registrar does not receive an affirmative response from the
Registered Name Holder, Registrar shall either verify the applicable contact
information manually or suspend the registration, until such time as
Registrar has verified the applicable contact information.
Having registered and renewed domains since July, and given that this was a renewal, the fact that I just got this for the first time does seem like the implementation has been delayed.
So by that language, yes, Network Solutions can do exactly what it is doing. Given Network Solutions' constant spam, constant final notice of deactivation messages that are not, in fact, final, and folded in with its dark patterns on the web site, I don't trust anything I get from Network Solutions as far as I can spit it. It doesn't help that I saw no notifications of this (unlinked) nameless regulation when I was in my account two days ago, so I also wasn't primed for it after I had just verified my contact information.
So what's the takeaway here? Don't do what Network Solutions does and you will have taken a big step to avoid being viewed as a spammer or phisher by your own customers.
As you can see in the comments below, one user commented on the Network Solutions blog post, was acknowledged, and then Network Solutions removed the commenting feature altogether. He was able to provide me with a screen capture of the comments (and reply) from Disqus:
Meanwhile, after telling me to click the link in the email (see above), NetSol is telling other users not to click links in email, "to be safe." This certainly doesn't help reduce confusion.
@deepsoul13 Just don't click on links to be safe! You should always keep your WP updated. ab
In late 2012 I related my extreme displeasure of trying to register a domain through the intentionally confusing Network Solutions ecommerce flow. In my post, Network Solutions and Dark Patterns, I used a whole lot of screen captures to show the convoluted flow that I believe Network Solutions uses to trick its customers into agreeing to add-on services (and cost).
I noticed a fresh one today as I had to go in and renew a personal domain and quickly recognized that it behooves you as the customer to read every piece of text Network Solutions puts on the screen, else you'll agree to things you did not intend. I walk through the process below (in far fewer screens than last time).
Upon Signing In
The screen immediately after logging in, with a form asking for contact verification.
As soon as I sign in, Network Solutions wants me to verify my contact information. This makes sense to me. After all, it's hard to notify someone that his/her domain name is about to expire when he/she has changed email addresses and not updated it here.
The text is straightforward:
To ensure that you receive essential information about your account and services, please confirm the contact information that we have on record for you.
Now the First Pitch
This screen is trying to get me to add the Private Registration service. Note the red italic style in the graphic for the word exposed.
Unsurprisingly, I am asked to buy into Network Solutions' obfuscation service. Using scary language, this is the first pitch to try to get me to add some services:
Your name, phone number, and address are listed in the public WHOIS database for your domain(s).
Apply Private Registration to your domain(s) to safeguard your personal information.
The phone book, among many other public databases, has had my information on file for years. I can skip this and its undisclosed costs.
Check Your Contact Information
This is where it goes all wrong.
This screen is ostensibly asking me to verify my email and phone number, but a careful read shows that's not the case.
Now I am presented with a screen asking me to Check [My] Contact Information. On my first visit to this page I was just about to click the submit button when I remembered that I had already confirmed my contact information when I logged into the site. So I opted to read the opening sentence:
Please confirm the contact information for Adrian Roselli to ensure that you receive important communications about your account.
Yep, this sounds like what I already did. Time to read the small print at the bottom:
* By submitting the contact information above, you expressly consent to Web.com and its affiliates contacting you regarding your services and offering new services via the contact information you provide (including your mobile number), via an automatic telephone dialing system or pre-recorded call. You are not required to give consent in order to make a purchase with us or our affiliates and you can find additional information in our Privacy Policy. Click here to remove your consent.
I emphasized the hyperlinks above. Affiliates. Privacy Policy. Click here. That last one is key. You have to click here to remove your consent. It's carefully hidden (note the red arrow in the screen shot above) behind the awful link text click here and suggests that I am already opted in.
I reproduce the small text on this screen below.
As I dutifully click there, the content expands to show me the following checkbox — which is unchecked:
I do not consent to Web.com and its affiliates contacting me through automated telephone dialing systems, pre-recorded calls or text messages on my mobile phone, or through pre-recorded calls on my residential line.
As I read that text I realize I am giving Network Solutions, and anyone it and Web.com deem worthy, the right to send me text messages. I note that because many people have to pay for their text messages. The robo-calls are just as annoying, of course, but I personally take umbrage with the text message approach.
Apparently I cannot not submit information.
I check the box and, just to be on the safe side, clear my phone number before I submit the form. I get this seemingly offshore-call-center-poorly-localized error message:
Please, fill the empty fields.
Once I enter a number again I am allowed to continue and am thanked with this absurd message:
Processing…
To be fair, that's not a dark pattern. However, waiting an additional 5-6 seconds after wasting a few minutes with this stupid process of trickery just to see an animated GIF imply that whatever is happening in the background must be so important to also affect my ability to spend my money warrants some mocking. Deep breath.
Conclusion
Network Solutions may be less evil than some other registrars (sideways glance at the despicable GoDaddy), but by all means read every piece of text and every button before you sign away your text message limits or, as in my previous post, end up paying for services you cannot cancel.
By the way, if I do accidentally give my permission, I challenge you to find where in the interface I can revoke that permission.