Microsoft.com has a new home page. It uses HTML5 and ARIA. I have done a quick review of their usage. There are a few issues…
home page accessibility – updated 05/02/13
language – 
fixed 06/10/12
The UK home page has a lang=”de” on the HTML element. This results in the page being pronounced using the German language setting in JAWS and NVDA.
Suggest they need to use the correct lang value: lang=”en”
<html lang="en">
search form – 
not fixed 05/02/13
The search form has a pseudo list box which displays the search choices and seach term matches.
It’s keyboard accessible via up/down arrow keys, but the presence of the list is not exposed to assistive technology, users will have no idea it is there.
Suggest, using ARIA to provide correct role, name, state and property information.
An example of a more usable autocomplete widget.
Use of ARIA roles to identify navigation links as a menu – not fixed 05/02/13
Code snippet from the navgation links menu:
<ul role="menu" bi_parenttitle="t1"> <li role="menuitem"> <a href="https://www.microsoft.com/security/default.aspx" bi_index="0" bi_cpid="hpMenu">Security Home</a></li> ... </ul>
First thought is, even if marked up correctly, it would be better not to identify the navigation links menu as a menu with menu items as they are a list of links in a web site not a menu in a web application. Adobe have also recently implemented a new navigation menu, it uses a hybrid keyboard interaction approach: tab and up/down arrow with minimal, but effective use of ARIA to indicate the presence of sub menus to AT users and interaction hints for keyboard only users. It is suggested that Adobe’s approach is more fitting to the context in which it is used.
The Microsoft menu bar does not work as it should. If interactive content is marked up as a menu bar with menus and menu items, its interaction behaviour should be that of a menu bar, it is not. The role information provided via ARIA indicates an expected and defined set of keyboard interactions. The ‘menu bar’ on the Microsoft home page has none of these.
If you test it with a screen reader, you will find a few issues…
Example of a menu bar widget that is suitable for a web application setting (in an embedded HTML editor, for example) and works as it should.
Suggest implementing a navigation links menu that provides appropriate semantics and works for keyboard and AT users.
ARIA landmark use – not fixed 05/02/13
The Microsoft home page, makes use of the ARIA search, navigation and contentinfo landmark roles, but for some unknown reason does not provide a role=main…
Suggest adding role=main.
<div class="grid-container" role="main"> ... </div>
HTML5 use
Uses the HTML5 doctype, section, header and footer elements and input type=search. These have minimal effect on accessibility as support for these elements is somewhat limited. The positive effect of using the HTML5 doctype is that when validating the HTML code ARIA use is not flagged as an error (maybe in this case it should be).
Conclusion
Surprised that user testing was not conducted, or if it was… Come on Microsoft you can do better. Note that this is no way an exhaustive list of issues.
Comments
Great stuff, just one thing, regarding the navigation, you first write “First thought is, even if marked up correctly, it would be better not to identify the navigation links menu as a menu with menu items as they are a list of links in a web site not a menu in a web application.” but then just above the suggestion you have the link to the menu bar widget. I think maybe it can confuse people to implement that sort of menu bar in a navigation 🙂
Hi Isac, have clarified, should not be confusing now (hopefully).
How did they forget “main”? Hopefully, they will put all content into landmark regions for usability. Perhaps they could get Cynthia Shelly to work with them.
Didn’t Paravel do this redesign, not MS themselves? This would be great feedback for Trent and the folks at Paravel.
https://trentwalton.com/2012/10/03/a-new-microsoft-com/
Hi Ryan,
thanks, have left a comment on the article.
I see you’re recommending certain implementations of an autocomplete widget and a menu bar. May I, as a sighted keyboard user, offer a few remarks on that as well?
I’m using Opera, which has spatial navigation using the shift+arrow keys. This vastly superior navigation paradigm (compared to linear tabbing, for sighted keyboard users) is, however, destroyed by both examples you link to.
– The autocomplete widget, when pre-focused by spatial navigation, captures all keyboard events that have arrow keys, also if the keystroke has a shift-modifier. In effect, my focus is captured by the autocomplete widget that I merely wanted to pass on my way to my real destination.
– The menu bar also grabs keyboard events that have arrow keys. In effect, when I’m using shift+down to reach links or form elements mid-page, I’m scrolling the menu bar instead.
Both examples make content impossible or at least much more difficult to reach.
Accessibility is a very varied landscape and solutions for some may be severe annoyances for others. This is one of the reasons I would have preferred native browser behaviour attached to ARIA-conveyed roles and states, instead of all authors trying to do their best at hooking scripts to make the keyboard work (which inevitably fails for certain users or devices).
I see this as a pressing reason to merely regard ARIA as a stop-gap measure, on our way to more future-proof solutions (i.e. well-defined and handled elements in HTML itself).
Hi Fabian,
Of course you may, and interesting remarks they are. It is always a problem to weigh up the needs of differing users. The use of the non standardized spatial navigation mechanism you cite is problematic. If it was standardized across user agents, it would make it practical to take it into account. At least in this case you can turn it off, and navigate the controls. If you choose to use a non standard (yet superior) method to interact with web content, then it is not surprising that you will encounter issues, unfortunately. It would be great to see Opera attempt to make their products work for users of assistive technology by implementing the standards.
The issue is that developers want to and do build stuff from HTML elements that are not supposed to be used in the way that they use them. If we could persuade authors to ONLY use HTML as intended and only use native controls for interactive UI, then the problem would be solved. Unfortunately we don’t live in such a world.
ARIA attempts to fill the gaps by providing standardized design patterns that emulate in many cases common UI interaction patterns.
Myself and others have been working for years in HTML web standards development to bring custom UI widgets and semantic structures into HTML as native features, it is not an easy task and sometimes gets significant push back from browser vendors. Significant parts of ARIA will not be implemented natively in the near future, so we have to work with what we have got.
I realize that, and have so for many years using a minority browser in a ‘non standard’ way. However, web authors could also make things work without too much trouble. If one could intercept bare arrow keys, not modified ones, the issues mentioned above would not be there.
In general, intercepting as little as possible sounds like a good idea that is violated here (which causes me a lot of trouble, in the largest of web services – which is why I’m nuancing your enthusiastic recommendation 🙂 ).
I’m hoping combined solutions can be reached here.
Hi Fabian,
Unsure what you mean, but have pinged my friend Hans who developed the Accessible jQuery-ui Components I pointed to as examples, maybe he can help.
Fabian,
While it is appreciated that Opera has made these assistive technology features,
– Opera has little or no market share and it is a proprietary implementation
– Most companies do no write their applications to support Opera for this reason.
– Opera is inaccessible to virtually all assistive technologies on every operating system platform
– Opera’s keyboard implementation, although helpful to you, is non-standard
– Standard controls would implement the same keyboard commands to be accessible (e.g. HTML5 datepicker).
– Most developers want greater flexibility over their UI and consequently don’t use many of the new standard controls in HTML5. That is why ARIA continues to grow in adoption.
– The keyboard paradigm where we use tab and arrowing is temporary and really is not an ARIA issue. It is a keyboard accessibility issue. This will be replaced by Indie UI device independent events that are driven multiple forms of input. The keyboard mappings and other forms of input that drive those device independent events will be defined by the browser and the platform. So, the keyboard/ARIA point you make is only a temporary limitation which all browsers, including Opera, will be able to address in the next 1.5 – 2 years.
Thanks Steve, that’s much appreciated!
The points you make on 1) market share and 2) being proprietary also go for 1) all or 2) most screen readers, and in general I find such arguments poor incentives for any a11y-related endeavour. Also, while a cynicist might argue that Opera doesn’t deserve being tested on or supported due to its lack of accessibility support, such an approach in the end doesn’t help users who chose Opera for what it does happen to offer.
(I fully agree with you on Opera’s overall abysmal accessibility support though, and have been somewhat active in trying to improve that.)
Your last comment on Indie UI is great! I hadn’t heard of that development yet, and it sounds like exactly the way to go for better accessibility and usability of web applications. Thanks for pointing me to that!
Hi Fabian, here is a link to the Indie UI working group info.
Cool.
Hi Fabian,
thinking about it some more, perhaps you should be asking Opera to fix their spatial navigation feature so it takes into account commonly used scripted interaction behaviours. The examples i pointed to are not unusual design patterns.
Steve,
I’ve thought of that, and in fact in case of pre-focus being trapped on form fields with event listeners I already filed bugs with suggestions on how to fix the issue.
I’m not sure how Opera could fix the problem for links (like in the menu bar example). Links are not pre-focused (like text fields are: these are outlined but you need to press Enter to get focus into them, otherwise you can simply continue navigating past the field) so they immediately get focus and thus key events.
Are you suggesting Opera use shortcuts for spatial navigation that don’t include arrow keys? That seems far-fetched, especially considering that Opera already abandoned its single-key shortcut set several years ago mainly for user expectation and web compatibility reasons. I can’t think of another easy solution that doesn’t throw the baby with the bath water. I’m not sure why you dismiss my suggestion to only sniff for non-modified arrow keys – do you think there are many people who use shift+arrows to select dropdowns or change menu selections? I would love to hear further suggestions here.
Also you and others seem to insist that spatial navigation is a non-standard feature. I think that’s dangerous. It is a widely accepted and documented interaction paradigm (it is also included in the various web specs), it’s just that Opera seems to be the only implementor. Also it’s an invaluable accessibility and usability improvement for sighted keyboard users. I find it painful to see a11y champions dismiss it so easily or consider it a pain to support.
I just checked the last beta of Opera and the case of text fields with event listeners trapping spatial navigation seems to be fixed. (As long as the text field with autocomplete capabilities only has prefocus not focus, key events are not captured by the form field but sent to the page, which has no event swallowing.)
The problem of links with event listeners isn’t (the menu bar example), and I wouldn’t know how to fix that from the browser’s side.
Hi Fabian,
I just tried using Opera (11.5 on Mac) spatial navigation with the widgets you find so problematic. To be honest I am having trouble understanding what the big deal is. When I move to the menu bar (for example) I can use the spatial navigation keys to navigate the menu, if i want to skip over the menu I can press tab then go back to spatial navigation. What am I missing?
Note that when ARIA roles are used they have an implied interaction model, just as native controls do, presumably Opera handles native controls by taking into account what keys they consume, they could do the same for ARIA roles that imply certain keyboard interactions.
Hi Steve,
Unexpected focus changes are always unsettling, and the user will have to figure out how to break out from focus traps. This may be different on every site where it occurs (and in some sites not possible at all).
Indeed, in this case it may be fairly straightforward if there is only one offending widget and using linear tabbing is still in your muscle memory (it’s hardly in mine though, a few years of using multidirectional navigation does a fair job of abolishing tabbing). The problem becomes more apparent if dynamic dropdowns and the like become more widespread and are used multiple times on a single web page. You can’t realistically switch navigation modes on every paragraph if your focus continues to get stuck.
Mind you: this is not a hypothetical example. Youtube made changes last year that did exactly that: grab focus and intercept navigation on all thumbnails in a page as each and every one got a dropdown widget on them.
Hi Fabian,
The menu example uses a standard menu interaction paradigm. You appear to be mixing 2 issues up here, non standard keyboard interaction implemented ad hoc (as in your Youtube example) and standardized keyboard interaction associated with defined control types such as menus. It should be noted that HTML5 includes (an as yet unimplemented) native menu feature, which would in all probability have the same keyboard behaviour implemented. Which is why I suggested Opera could (when an aria widget role such as menu is encountered) implement appropriate keyboard behaviour for their non standardized spatial navigation interaction feature.
I think that Microsoft’s new design language (that was called Metro at one point) is both visually appealing and gutsy. And their new site is certainly interesting and even uses responsive web design.
But it is unfortunate that the markup contains a very large number of errors and it does remind me a bit of a web page exported from Word. But maybe this will improve over time as more parts of the site are updated with the new design.
The Swedish version of Microsoft.com still uses
lang="de"(I would uselang="sv"orlang="sv-se") as I am writing this on October 07, 2012 so at least some locales still have this issue.Hi Peter, I also like the new design. I had a look at the code, most errors are due to use of ‘bi’ schema attributes. I cannot imagine they would cause any issues. Too bad about the misused lang values…