Still Guessing on Accessibility

I have no illusions that accessibility on the web can be tricky. It's primarily tricky because of the way developers choose to implement it. Web Axe nicely sums it up:

Most people don't realize that the web IS accessible. The problem is that designers and developers break it.

— Web Axe (@webaxe) January 28, 2013

Part of the reason developers break it is because they make assumptions about disabled users. I feel there is a trend toward assuming all disabled users are blind, all blind users surf on JAWS, all JAWS users have the same version, and this version is configured in the same way for all users.

But that's nowhere near true. The spectrum of disabilities runs from cognitive impairments through physical impairments, from dyslexia to no motor control. The spectrum of vision impairment alone runs the gamut from colorblindness, to full blindness, from age-related vision loss to at-birth loss. Even from normally-sighted users in ideal lighting conditions to normally-sighted users at an awkward viewing angle with the sun on their LCD screen.

When we think of only one disability we treat all disabled users the same. When we get feedback from one user with an issue we ourselves cannot comprehend, we tend to apply it to all users. You can learn plenty one user at a time, as I did from a web developer with dyslexia and dyscalculia. But just as a focus group of one is not adequate to extrapolate to all your users, finding one user with one variant of an impairment doesn't translate to all users with all forms of disabilities.

All of this swirled around in my head as I read two well-meaning posts from two respected web developers that, both in the original post and in the comments, show a whole lot of guesswork:

• Navigation in Lists: To Be or Not To Be, January 29, 2013 by Chris Coyier.


• On Alt Text, January 30, 2013 by Jeffrey Zeldman.

I think it's great these posts were written, even if I think we should be beyond this. While I disagree with some of the arguments in the posts, and many of the arguments in the comments, you'll find that both posts lack direct feedback from the users they purport to be supporting. The comments are littered with people guessing and asserting what disabled users need, but with little to back it up.

As you read through you will find a lot of justification built around how easy it is for the developer or how the developer thinks the user wants to "view" the content.

Posts that would benefit from comments from screen reader users:
Navigation in Lists css-tricks.com/navigation-in-…
On Alt Text alistapart.com/blog/post/on-a…

— Adrian Roselli (@aardrian) January 30, 2013

As commenters with experience working with accessibility or using accessibility tools weighed in, it still felt like the other commenters and the original authors didn't quite like the answers they were hearing.

And so we are, some 20 years after the rise of the web, still guessing how to implement accessibility. As a community, we're happy to build device labs where we can let people test on every conceivable mobile device, but we aren't building the same thing for accessibility. I am fortunate to have had a good deal of experience with disabled users both in my community, among my clients, and in my personal life. I am not so sure we as a web development community can claim that.

If you do wade into the comments on both articles, I recommend you read John Foliot's comment on the A List Apart article, even if others seem to dismiss it. In the CSS Tricks article, Louis Lazaris collects a nice set of references and Léonie Watson provides a quick straw poll of users. Ultimately Chris Coyier gathers some of this feedback.

The Upshot

People are talking about these issues. These two posts provide far more handy, contextual discussion in the comments than most web developers will bother to do on their own.

Related

I've had plenty to say about the alt attribute in the past (for example, let's not call it an alt tag). But with some people asserting that alt is no longer required in HTML5, it's easier to just link to my own retelling of why that's the case in HTML5 and why I think it's a terrible idea.

• Image alt Exception Change Re-Re-Requested, June 11, 2012.


• More on Image alt Requirement in HTML5, May 2, 2011


• Image alt Attributes Not Always Required in HTML5, April 19, 2011

Update: February 1, 2013

There is a comment on the A List Apart article from Marc Drummond that outlines cases where a description in the alt attribute, in this context, is useful to users

Dennis Lembree (Web Axe) has added to the meta discussion with his post Leave Accessibility to the Experts Please. It's worth reading the whole post and the ensuing comments to get the whole picture instead of just reacting to the title.

Update: February 4, 2013

Turning the proper application of alt text into a popularity contest (ok, I know that's not quite fair, but that's how it feels to me), CSS Tricks has a poll for alt Text Usage. With no context (what else is on the page, does the graph get explained later, why use a graph if a table can do the job, etc.), it's not exactly a fair question. There are, however, a few good comments among the rest that try to set people straight.

Read More

My Viewport Sizes

Yes, that is my two monitor set-up — one display at 1,920 × 1,080 (with a browser at whatever size will fit my tabs) and one at 1,024 × 1,280 (with a browser always at 1,024 × 1,024). My browser reports two different screen resolutions depending which display the browser is using.

During the last rebuild of my site at least two years ago I started to track the viewport sizes of my visitors via Google Analytics. Since I don't care much about screen resolution (screen size), I don't bother to track it.

Yesterday I saw a post that tracks screen sizes between technical and not-so-technical visitors to the author's site. While the information is interesting, it doesn't include any viewport data, which happens to be what I care about.

This motivated me to jump into my Google Analytics and pull the viewport data that I have. The chart below represents what I found:

What I've done is grabbed the last 500 visits to my site for which I have data (even bad data) and plotted them in a scatter chart without regard to the frequency of a particular resolution. To be clear, this isn't scrubbed data and it's not from a site targeted at the general web user.

The block of code I use to get this data into Google Analytics does the job. I borrowed the code from the post Measuring browser viewport size with Google Analytics, though I make my viewport(); call at the end of the page, not in the body.

function viewport() {
  var myWidth = 0, myHeight = 0;
  if( typeof( window.innerWidth ) == 'number' ) {
  //Non-IE
  myWidth = window.innerWidth;
  myHeight = window.innerHeight;
  } else if( document.documentElement &&
 ( document.documentElement.clientWidth
 || document.documentElement.clientHeight ) ) {
  //IE 6+ in 'standards compliant mode'
  myWidth = document.documentElement.clientWidth;
  myHeight = document.documentElement.clientHeight;
  } else if( document.body &&
 ( document.body.clientWidth
 || document.body.clientHeight ) ) {
  //IE 4 compatible
  myWidth = document.body.clientWidth;
  myHeight = document.body.clientHeight;
  }
  _gaq.push(['_trackEvent',
   'Viewport',
   'Size',
   myWidth+'x'+myHeight]);
  _gaq.push(['_trackEvent',
   'Viewport',
   'Width',
   myWidth+'x'+myHeight,
   myWidth]);
  _gaq.push(['_trackEvent',
   'Viewport',
   'Height',
   myWidth+'x'+myHeight,
   myHeight]);
}

Hopefully that's enough to get your started on tracking viewport stats for visitors to your site. If you see ways I can improve it, then please do let me know. I can update this and we can all benefit.

If you are curious why I chose to skip tracking screen size and just focus on viewport size, I refer you to an article I wrote 13 years ago, along with more recent articles from me and others.

• Real-World Browser Size Stats, Part I, July 4, 2000.


• Real-World Browser Size Stats, Part II, July 4, 2000.


• Browser viewport statistics, November 10, 2009.


• Screen Resolution ≠ Browser Window, June 17, 2011.


• Browser screen resolution stats rile devs, April 13, 2012.


• Where's the Viewport Size Data? April 13, 2012.

Update: February 15, 2013

Welcome, visitors from the below tweet. Please post your own comments or even your own stats. I would love to see them.

What if we stopped measuring screen resolution and started measuring browser viewports instead? - bit.ly/149AFpk / cc: @ppk

— Smashing Magazine (@smashingmag) February 14, 2013

Update: November 13, 2013

To quote PPK, screen.width is useless. Devices don't consistently report device pixels or viewports in a consistent way. There is clearly still value in having some numbers, though the quality of those numbers is always suspect.

Read More

App Store Meta Tags

Why yes, Dominos, I'd love to tap again to get your real home page to order a pizza when I could have done it right here, below your over-sized app pitch that could be done in a tiny ribbon.

This may be old news to some of you, but I haven't found a place that collects this in one spot.

One of the most offensive experience I have when surfing a site on my mobile devices is being forced to click through an advertisement for the site's app in the iTunes store (even moreso when I am surfing on a non-iOS device). There is a fair number of sites I have tapped away from because of this (I also don't expect to be served the page I came to see, but instead shunted to the mobile home page).

If yours is one of those sites, whether promoting your entire user experience or just a product, there is a less offensive way to present your pitch to users on iOS and Windows Phone.

iOS 6

Safari on iOS 6 and later devices can promote your app with a standardized banner. Essentially you stuff a custom meta tag into your page that references your App Store ID. If the user already has the app installed, then the ad becomes a launcher instead.

The code is pretty simple:

<meta name="apple-itunes-app" content="app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL">

• app-id is required and references your app's identifier.


• affiliate-data is optional and uses your iTunes affiliate string.


• app-argument is also optional and can allow users who have your app installed to jump to a specific place in your app.

More details at Apple's developer site: Promoting Apps with Smart App Banners

Windows 8

Microsoft offers a similar feature for users of Windows 8 in non-desktop mode who are also using Internet Explorer. I have not tried it, so I cannot explain how this works as the user changes modes nor how it works with the "charms" feature of Windows 8.

This code is relatively simple as well, though it requires two meta tags and supports up to five:

<meta name="msApplication-ID"content="microsoft.build.App"/>

<meta name="msApplication-PackageFamilyName"content="microsoft.build_8wekyb3d8bbwe"/>

• msApplication-ID is required and references your app's identifier.


• msApplication-PackageFamilyName is required and contains the package family name created by Visual Studio.


• msApplication-Arguments is optional and lets you pass arguments to your app.


• msApplication-MinVersion is optional and can direct users with an old version to the Windows Store.


• msApplication-OptOut< is optional and allows pages to opt out of installing the app, switching to the app, or both./li>
  

More details at Microsoft Developer Network: Connect your website to your Windows Store app (Windows)

Google Play, BlackBerry App World, Etc.

In addition to Google Play, BlackBerry App World, I looked for similar features for the Firefox OS and Ubuntu Mobile stores. I know there are other mobile platforms out there for which I did not look.

If you know of other apps tores that offer similar features, please let me know so I can update this post.

Related

There are other places where custom meta tags are used to display targeted content. One example is used for Twitter Cards and another example is used with Google News. While you can build support for them, neither Twitter nor Google is going to use them unless you have been vetted in advance.

Updated: January 29, 2013

I wrote a version of this post with an example at the Algonquin Studios blog. I'm pasting the example in here...

Real-World Example

One of our spin-off companies, SWRemote, has an app available for iPads. There is value in promoting the app to visitors of the site but not in blocking their access to the site content with a splash page or an extra click, especially if they are not on iPads. The SWRemote web site is powered by QuantumCMS (yes, I am promoting our web content management system), which makes it about 30 seconds of effort to add the necessary meta tag to the site.

Screen shot of the QuantumCMS custom meta tag screen.

If you are already a client of ours on QuantumCMS, all you have to do is choose Site Configuration from the Settings menu and pop into the Marketing tab. This is the screen that allows you to add custom meta tags. Press the Advanced button and you are off to the races. In the Name field, for this example, I just entered “apple-itunes-app” and in the Content field I provided the custom ID for the app appended to “app-id=.” As soon as I hit Save the web site was showing the app bar to visitors:

Screen shots of the SWRemote site on an iPad3 both with the app installed and without it installed, showing how the bar changes its message.

Oddly, even though the app runs on the iPad Mini, which is running iOS6, the app bar never appeared on the site when viewed on the iPad Mini. On an iPhone 5, the app bar started to appear and then disappeared — probably as the device recognized that there is no iPhone version of the app.

If/when there is an app available for Windows Phone, the process to add this feature will be the same, allowing the site to promote both apps dependent on the audience. QuantumCMS helps make the process easier, with no need to code any changes to your site templates.

Update, March 8, 2013

What he said:

I think "Download our app!" is the new "Skip intro…"

— Jeffrey Veen (@veen) March 8, 2013

Update, April 24, 2013

There is a recap of recent rants over at .net Magazine in the article "Devs rally against mobile web doorslams."

Update: June 12, 2013

Google has just announced that it may penalize sites that promote apps with those awful interstitials. Yet Google offers no solution (as you see above) for Android apps through the Google Play store. You can get more detail in my post "Google Needs to Provide Android App Interstitial Alternative."

Read More

Facebook Graph Search and Lessons from Timeline

Facebook has announced its new Graph Search feature which allows logged in users to search for information across their friend profiles. Facebook even made it a point to set up a page about privacy in the graph search to try to head off concerns from users.

In this case, Facebook may over-estimate its users. Do you remember when Facebook rolled out its timeline to everyone? Do you remember all the cries of privacy violations in the form of exposed private messages and old relationship details? I do. I recall that it all boiled down to user's misunderstanding the feature and forgetting that they had publicly written and posted some things that might not look so good to them now.

I remember these headlines:

• Facebook resurrects old posts on Timeline, panic ensues, September 24, 2012 at CNet.


• Facebook May Be Publishing Your Old Private Messages On Your Timeline Or You May Just Have Been Lamer Than You Remember, September 24, 2012 at Gawker.


• Despite statements from Facebook to the contrary, users are still claiming to see private messages in their Timelines, September 24, 2012 at The Next Web.


• Update: Facebook Confirms No Private Messages Appearing On Timeline. They’re Old Wall Posts, September 24th, 2012 at TechCrunch.


• Facebook Users Say Private Messages Appear Publicly [UPDATED], September 24th, 2012 at Mashable.


• Are private Facebook messages becoming public? September 24th, 2012 at CNN.


• Facebook Users Convinced Years-Old Private Messages Are Being Published On Timelines. (But They're Wrong.) September 24th, 2012 at Forbes.


• Facebook on Privacy Scare: Nothing to See Here, September 24th, 2012 at The Wall Street Journal.


• Facebook privacy fears: Timeline trash or French farce? September 25, 2012 at Computerworld.

Let's see if the Facebook user base on the whole can remember a lesson not even four months old — lock down the stuff you don't want people to see in a search.

Complained about your co-worker? Remove it. Pictures of your former significant other? Hide them. Bragging about that thing you didn't win? Purge it. Denying the holocaust? Go to hell.

If you aren't sure how to do that, Google can probably point you to a pile of tutorials.

Update, Jnuary 23, 2013

• Actual Facebook Graph Searches Don't worry, we'll all be used to this in a few weeks' time.


• How To Use 'Graph Search' To Facebook-Stalk Mark Zuckerberg And His Employees

Read More

Letting Mobile Users See Desktop View of RWD Site

Bruce Lawson tweeted out a seemingly random musing today that I have pondered myself — what if, while on a mobile device and surfing a RWD web site, I want the desktop version of a site?

There are many reasons as a user that this might be the case, ranging from poor development practices that hide chunks of content you need to see to just wanting to know what it looks like.

Clearly it's enough of a use case that mobile browsers such as Opera Mobile, Chrome, Firefox, and so on, have a feature to request the "desktop" version of a site from a menu built into the browser.

Except that feature doesn't work with a RWD-powered site because media queries, typically based on viewport width, are used to deliver styles for traditional desktop window sizes. The browser feature only sends a different user agent string (bypassing terrible user agent sniffing) but doesn't do much else. Your 320-pixel-wide device is still 320 pixels wide, and the media queries know it.

Until the mobile browser makers report a false viewport (or, rather, assume one when choosing CSS from a set of media queries), we're kind of stuck. While I have many ideas on how that might work, that won't address the issue today.

While I had bandied about an idea to address this on the redesign of my site a couple years ago, it took a client request last year to get my team the time to finally code a solution.

There are some core steps the hammer out in the logic of any solution:

1. Put a link on the page to view the desktop layout. I prefer to have it in the raw HTML over writing it in with script.


2. In the more mobile-friendly CSS files allow this link to display. In the more desktop-friendly CSS files hide the link.


3. Either using a round-trip to the server or client-side script, remove the media query logic and serve up the "desktop" CSS.


4. Warning for Europeans: cookies. Set a cookie with that preference for the user. Whether it is for the current session, forever, or somewhere in between is worth an internal discussion.


5. Now display a link to view the "mobile" version of the site. Again, this can be done with or without script.


6. If the user clicks the link to see the mobile version, re-instate all your media queries, clear the cookie and pretend nothing happened.

This process is a bit oversimplified, but it covers the broad strokes.

There are some hurdles, of course. Your users might not understand what you mean by "desktop" or even "mobile." You could make the link to get out of one of the views too hard to find. You could bump up against expectations set by the mobile browser feature to request the desktop site. If you serve mobile styles to IE6 users, you could confound them if you don't clear the link from the page for them. And so on.

You can play around with what we implemented for our client at CHSBuffalo.org. View the source to see the styles and script. There is obviously logic on the server side, but you can make up your own for your own server platform.

These screen shots should give you an idea of what to expect when you visit the site:

The CHSBuffalo.org site as seen on an iPhone and on a Nexus 7, all styling determined by media queries.

The CHSBuffalo.org site as seen on an iPhone and on a Nexus 7 after clicking "View desktop layout" (with the zoom as the user would initially see it). The link to return to the mobile layout is at the top, though not as obvious as it could be.

This is what the user on an iPhone sees as soon as the desktop view loads—note the link to return to the mobile view is nowhere to be found. We did a poor job there and will have to fix it. Don't make the same mistake if you try this.

Related

• Turning off responsive web design, January 12, 2013 from Bruce Lawson.


• Opt-Out Responsive Design? September 12, 2012 at CSS-Tricks.com.


• Creating a faux ‘View full site’ button for responsive sites, May 26th, 2012 at NeilCarpenter.com.


• View Full Site Link for Responsive Web Design, April 12, 2012 at CreativeAndCode.com.

Update: March 25, 2013

In this post, Roger Johansson shows code the code behind making his similar technique work: Letting users disable responsive layout.

Update: March 29, 2013

Two more posts popped up this week around the idea of disabling responsive design, both of them looking a bit at the larger issue and then proposing an icon to toggle a design between responsive and non responsive: Thoughts on Toggling a Responsive Design On and Off by Jordan Moore and A suggestion for Responsive Design toggle icons by Andy Clarke.

I'm of the opinion that icons only mean something to a sub-set of users, so relying on them may be inadequate. I still like plain text.

Update: May 3, 2013

An article over at SitePoint asks "Should Users Have the Option to Switch Off Responsive Design?" The author tends to think that such an option is superfluous and many of the commentors agree. Many others point to bad RWD implementations as a reason to offer the option (though the developers of those bad RWD examples probably wouldn't care about letting users disable it). An interesting read if only to see more opinions.

Read More

Google Maps: Misbehaving with UA Sniffing

Here's the TL;DR: Google Maps sniffs a browser's user agent string. If it finds Internet Explorer on Windows Phone, then it kicks it over to the m.google.com mobile home page.

So let's be clear. It's 2013 and one of the biggest companies on the internet is using a sniffer to redirect users on a browser and platform that it sees as competition.

Google's general claim is that the mobile version of Google Maps is optimized for WebKit browsers (such as Google Chrome) and therefore Google doesn't support non-WebKit browsers. Even though Google Maps works fine on Firefox mobile (which supports panning, but not pinch-to-zoom) and Opera Mobile (which sometimes supports panning, but not pinch-to-zoom), neither of which uses the Webkit engine. It even renders using Opera Mini, although I can't get it do anything. I can't test Internet Explorer on Windows Phone because I don't have it.

I can, however, test Google's browser sniffer by changing the user agent string in my browser to report itself as Windows Phone and watch my request for maps.google.com get redirected to m.google.com, the Google mobile home page. This tells me that Google isn't performing feature detection (such as touch events or multi-touch support), but is instead damning the browser by name alone.

This is the lesson Google is teaching young web developers who don't understand how flawed this approach is (contrary to its own instructions on best practices from less than a month ago). Google Maps happily lets me have a sub-par experience in Opera Mobile or Firefox mobile. It even lets me have a broken experience in Opera Mini. But Internet Explorer on Windows Phone? Google Maps just boots those users.

Reports I have read (and watched) on assorted articles online suggest that Google Maps works reasonably well on IE on Windows Phone (supporting panning and pinch-to-zoom). As such, I don't buy Google's argument that it wants to prevent users from having a poor experience—there is already evidence that a large number of users (more than use Windows Phone) are having a poor experience.

From Google:

The mobile web version of Google Maps is optimized for WebKit browsers such as Chrome and Safari. However, since Internet Explorer is not a WebKit browser, Windows Phone devices are not able to access Google Maps for the mobile web.

…Because we actively block them, should be how that quote ended.

So why is Google really doing this? Is it because it's fun to pick on Microsoft? Is it because Google thought it could get away with it? Is it to make the Windows Phone experience less appealing than Android's? Is it because Google doesn't like Microsoft's touch events specification (and how well it's been received) at the W3C? Is it because of recent court cases between Google and Microsoft?

In this case I don't much care. I care instead about the terrible example Google is setting for web developers.

Background

• Google Maps Has Never Been Accessible On Internet Explorer Mobile Now Blocked on Windows Phone (Updated), January 4, 2013.


• Now Google is blocking Windows Phones from accessing maps.google.com, January 4, 2013.


• Many Windows Phone users report being cut off from Google Maps (update), January 4, 2013.



• Google Maps never supported Internet Explorer on Windows Phone 8, and it likely never will, January 5, 2013.


• Shenanigans: Google Maps redirect issue on Windows Phones is a matter of competition, not compatibility, January 5, 2013.


• This is Why You Can't Access Google Maps on Windows Phone, January 5, 2013.



• Google Admits It Was Deliberately Blocking Windows Phone Users From Google Maps, January 6, 2013.


• Google says Maps redirect on Windows Phone was a product decision, and will be removed, January 6, 2013.


• Windows Phone Doesn't Support Google Maps Because Google Doesn't Want It To, January 6, 2013.



• Google Maps, Windows Phone, and an avoidable mess, January 7, 2013.

My Related Posts

• Let's Treat Old Browser Users Better, July 5, 2012.


• Another Anti-IE Gimmick, June 14, 2012.


• Exclusion Is a Feature Now, May 10, 2012.


• The Return of “Best Viewed in…”, March 4, 2012.


• Detecting Mobile Devices — Don't Bother, October 11, 2011.

Read More