Microsoft versioning: accessibility implications

I’m still working out my whole response to the Microsoft versioning idea (and feeling sad as the WaSP eats itself).

But there’s one practical problem with the suggestion that pages without the MMM™ (Magic Microsoft Metatag™) become ossified under IE7 for all time. IE7 (and its predecessors) makes some in-page links entirely inaccessible to keyboard users. Yes—completely unreachable to blind people and those with motor impairments.

Read Gez Lemon’s Keyboard Navigation and Internet Explorer article for a full investigation of the problem, but in a nutshell:

…when using the keyboard to navigate to an in-page link, pressing the tab key once the target has received focus causes IE to continue navigating from the start of the document (or more accurately, the closest ancestor with the hasLayout property set to true).

If you have IE7, you can check out my IE7 keyboard navigation test page. Activating the first link should put focus in the last paragraph; a further tab should take you to the very last link on the page. But IE just takes you back to the top, making that link impossible to reach.

There are code workarounds—but if a site-owner doesn’t know to add the MMM™ to the top of their pages, they’re unlikely to know or care abut those workarounds.

So freezing the web to IE7 levels consigns much of it to perpetual inaccessibility.

17 Responses to “ Microsoft versioning: accessibility implications ”

Comment by patrick h. lauke

also, quite generally, i wonder what assistive technologies are supposed to do when hooking into IE8 and beyond. will IE7 legacy rendering and the new rendering engine expose the content in the same way, or will screenreaders etc also have to implement two or more separate API layers and stuff to present content to their users? if it’s the latter…shitehawks!

Comment by David Storey

For what its worth, it will be a similar situation with security. If there is an exploit in a version of IE, and the fix means changing layout or behaviour of JavaScript/DOM somehow (just like how Opera disallows scripting across domain now, or even to some degree how we disable encryption that is now considered weak), then either IE will have to bake that exploit in IE forever (incredibly unlikely) , or “break the web” by making the existing engines also include the fix.

Comment by thacker

Keyboard navigation is, also, a problem within ASP.NET Web apps that include the CSS Friendly Control Adapters within the NET app. The problem has long been documented.

Both of these keyboard issues are resolved by always assigning proper tabindex values.

—-

Lauke-

An excellent source to answer your question would be direct contact to GW Micro –the Window Eyes people .. support-at-gwmicro.com. These guys are always happy to answer questions.

Comment by bruce

thacker – whether or not tabindex solves the inpage navigation problem, my main point still stands:

“There are code workarounds—but if a site-owner doesn’t know to add the MMM™ to the top of their pages, they’re unlikely to know or care abut those workarounds.

So freezing the web to IE7 levels consigns much of it to perpetual inaccessibility.”

Comment by thacker

Lawson–

By no means did I or am I disputing you and the keyboard navigation issue. However, legacy Web sites have much larger problems with accessibility than just keyboard navigation. In my opinion, the use of tabindex values is as routine, or should be, as use of a proper DTD.

I consider it a stretch to presume that future versions of IE will be locked into IE7 rendering as the default.

Thank you very much.

Comment by Scott

@ Thacker:

The current version of the proposal calls for IE7’s rendering to be the default for any unspecified page. I hope that you’re right and it doesn’t become reality.

Comment by thacker

Scott–

I apologize for any misunderstanding in my remarks. It should have read, “[..] future versions of IE, beyond IE8, will be locked into IE7 [..]”. Conjecture is what it is.

Thanks.

Comment by patrick h. lauke

thacker – the meta/http-header switch in IE8 is a stay of execution that lets MS innovate without “breaking the web”, in their words. what makes you think that, by the time IE9 comes out, those entrenched intranet apps and lone sites written specifically for IE (which would break spectacularly in IE8, hence the switch) will be any more standards-compliant to warrant dropping the switch?

Comment by thacker

Lauke–

Simply put, market forces and the pressure the market brings to bear. For IE6 based Intranets, new browser releases are indirect forces and those take longer to impact a business than do direct market forces. As a business’s customers, vendors, employees and others migrate to future releases through and beyond IE7, that pressure will increase.

For CMS and Web development applications, since the sunset of FrontPage, browser releases are direct market forces of significant impact. Changes will occur within these software applications while the applications are still able to offer a low technical cost of entry for their customer base.

I don’t expect abandonment of the IE meta tag in IE9. However I do expect abandonment of it within IE10. I believe in IE9, there may be a need of legacy IE6 content to directly specify IE6 within the tag.

As I have stated in other blogs regarding this issue, when an immediate course correction is necessary, it is easier to maneuver the ship than it is to move the ocean. This meta tag, initially, will do that while the latter occurs over the next two to four years.

Understand that my logic and reasoning is a little more in-depth than what is available for presentation with a blog post. It also comes from a mind that is not trained or used to design or develop Web content.

Thanks.

Comment by patrick h. lauke

“For CMS and Web development applications, since the sunset of FrontPage, browser releases are direct market forces of significant impact.”

but if the release of the dominant browser still defaults to compatibility with their outdated, non-compliant code, then the force is exactly zero…so i don’t quite get your point here.

Comment by Bruce

Thacker, you’ve piqued my curiosity: you say “the use of tabindex values is as routine, or should be, as use of a proper DTD”.

I’ve never found any use for tabindex on well-structured sites, but I don’t want to rule it out. Can you give me an example of when a site made with semantic markup is made more accessible with explicit tabindex (except to counteract the IE bug discussed above)?

(Can I ask another favour? Can you call me “Bruce” rather than “Lawson”? We’re not in the military on my website!)

Comment by thacker

Lauke–

I respectfully disagree that the default of IE8 to the IE7 engine represents a zero market influence upon CMS application development. Its influence needs to be accounted for not only for the application’s customer base but also for future releases of Internet Explorer. Granted, development applications such as Adobe Dreamweaver will account for it sooner than a development application such as GoDaddy’s Web Site Tonight. That is a difference of their customer demographics rather than any presumption of a ‘zero’ market influence based upon any browser dominance and/or lack thereof. Both will require time and that is what Microsoft is giving to them.

To presume that Internet Explorer will be set to IE7 as a default into perpetuity is a wide stretch. Arguments of prior acts using IE6 as an example to support such arguments are significantly out of context, in my view. I only present this in that such argument has been made by many in belief that Microsoft is a total moron and will lock such a thing down, forever.

Thanks.

—————-

Bruce–

I will acquiesce to your request even though the basis for my reference to an individual’s surname over that of the individual’s christian/given name is that it breeds familiarity with someone whom isn’t personally known. Such a thing, to me, is disrespectful. As you pointed out, its a jarhead thing.

I am sorry but I cannot cite any specific Web site, from direct memory or wherein I have bookmarked such a site, wherein failure to assign tabindex values presents keyboard navigation problems. Over the years, I have run across many, whether or not they were semantically correct, I do not know. [That preceding statement would last long if this were a court of law, huh.] A lot of those navigation issues could be a result of failure of the content to be laid out in a linear and logical order. If a specific site suffers that problem, assigning tabindex would reduce that problem. Granted, such a ‘fix’ would be ass backwards to a more significant problem.

In defense of tabindex, several years ago I was managing a project that included a form control. Within this specific form, there were three buttons. For this explanation, the buttons are labeled A, B and C. Logic of the form required that button B take initial focus because it was the most prevalent response to the form. As I recall, keyboard navigation order was not following logical order within the form which was, button B, then button A and lastly button C. Assigning tabindex resolved this issue however it also required assigning tabindex values to all necessary links, form controls, etc that preceded this specific form. It looks as though this was is a similar issue that you pointed out in your thread. From that point on, all managed projects required assigning tabindex values.

Some will argue that such use adds un-needed bulk to the code in that same manner they have argued that use of the IE8 meta tag version switch adds un-needed code. I compare such arguments to the body mass index of muscle mass versus body fat. Some body fat is a good thing and that, however, too much towards lean or vice versa is rarely good.

In addition, when creating ASP.NET standards compliant content, either hard-coded or using Visual Studio 2005/2008, use of the CSS Friendly Control Adapters is necessary. However, one drawback when using these adapters is that tab order of any one of these controls falls to the bottom of the tab order on any given content page wherein the adapter is used and regardless of its linear order within the content. Use of tabindex resolves that issue.

Use of tabindex can be cumbersome. Much of this is reduced if tabindex values are assigned as blocks based upon the various segments of the linear layout of the content. I simply consider it a best practice in the same manner, for example, that a modified version of the United Kingdom Standard for accesskey values and the ICRA label should always be used. I concede that the majority of my views are, more often than not, in a distinct minority.

Again, please forgive me. I am at the age wherein I recall the creation of hydrogen but cannot recall what to hell I had for breakfast.

Thanks.

Comment by craig elliott

with regards to your comments about tabindex i think they are well founded. i base them on pure logic as that is the only way i can see around the problem they create. i also remember access key vaguely.
i like your use of the word prevalent/ although i adopt inherent. as for adding values in other words strings they are too complicated for me. machine code is the basis on which all ip 7 levels should be regarded but is there a law to stop them. i have tried making sense out of microsoft but i am stll lost. the new levels may come into future effect as i wouldn’t be suprised if dell were now using them. as for icam client a good idea in principal but mainly unfounded. thats if you use human logic!
also nitrogen seems to be all i live on – as oxygen is at a premium.

Comment by Bruce

“nitrogen seems to be all i live on – as oxygen is at a premium”

Absolutely, Craig. An insightful contribution.