Notes on comments.
Welcome to our blog dedicated to the engineering of Microsoft Windows 7
This post is from Michael Bernstein, a development lead on the User Interface Platform team where he focuses on accessibility. Accessibility is the term we apply to the APIs and features that enable Windows to be used, to be accessible, by as many people as possible so that, regardless of physical or cognitive abilities, everyone has the ability to access the functions of Windows. To enable this, Windows includes both built-in accessibility utilities as well as APIs used by third party assistive technology aids and by application developers to make sure their software is also accessible. This is a topic that is extremely important to Microsoft and one that is a key tenet in the engineering of Windows 7. Microsoft also has a corporate-wide group dedicated to making sure that PCs are easier to see, hear, and use. You can read more about Microsoft’s accessibility initiatives on http://www.microsoft.com/enable/. --Steven
Hi, I’m the development lead for Accessibility and Speech Recognition experiences in Windows 7, and I wanted to write about how we thought about Accessibility in Windows 7.
We wanted to make Windows 7 the most accessible operating system that Microsoft has ever produced. It became clear as we planned this release, however, that the notion of Accessibility is not as simple as it may appear. It is tempting to think about Accessibility like Security: either you have a known failure, or your system is believed to be secure/accessible. This definition turns out to be limited, though. How do you deal with the fact that the needs of customers who are blind are very different from the needs of customers who are deaf? The needs of customers who are blind are even different from those of customers with reduced vision: a magnification tool is useless for one group and crucial for the other. And what do we make of cases where something is technically accessible but practically frustrating, like a common user scenario that takes 36 keystrokes to execute? Clearly, Accessibility wasn’t going to boil down to a simple yes/no question. It is really more like a particular kind of usability, but usability for a specific set of audiences with individual needs.
Since the questions we were asking were complex, the answers ended up being complex, too. We chose a four-part strategy to improve Accessibility in Windows 7.
In Windows Vista, Microsoft delivered a new core component for Accessibility called UI Automation. UI Automation enables a user’s assistive technology (AT) to programmatically drive the UI of an application, and allows applications to expose their accessible functionality in a richer way than was possible in previous versions of Windows. More questions can be asked about a piece of UI, and that UI can be manipulated in richer ways. UI Automation also introduced the idea of Control Patterns: any given piece of UI can decide how it should be controlled. Buttons expose the Invoke pattern, indicating that they can be pushed; Combo Boxes expose ExpandCollapse, indicating that they can be opened and closed. We let different controls be different, instead of trying to force them all into the same mold. All this was introduced in Windows Vista and adoption is still ongoing.
In Windows 7, we invested in improving the performance of the UI Automation system and created a new, native-code API for UI Automation to make sure that it can be used effectively by a wide range of assistive technology software. Now applications written in C++, as well as those written using the .NET Framework, can take advantage of UI Automation.
We also did a bunch of work to make sure that the UI Automation system was integrated even more closely with the legacy Microsoft Active Accessibility (MSAA) system and developed new bridging techniques between the best of the new and the old technologies. UI Automation Clients can read Accessibility information from MSAA applications, and vice versa, to ensure maximum Accessibility regardless of which accessibility API an application used originally. Since the UI Automation and MSAA systems cooperate closely in many scenarios, we decided to name the combination of the two, calling it the Windows Automation API. This architecture forms the foundation for the rest of our Accessibility effort, and we’re pleased to have this Accessibility foundation Windows 7.
We also improved the Accessibility utilities that we include in the box with Windows. Microsoft works closely with many different AT software companies who deliver software to make Windows more accessible to customers with disabilities, but we also include a set of utilities to make sure that our customers’ early experiences are accessible, even before installing any other software. We decided to enhance two of those utilities in Windows 7: the On-Screen Keyboard and the Magnifier.
The most noticeable change to the On-Screen Keyboard is the improved look and feel, but there are also more subtle enhancements. The appearance of this utility had not changed since Windows XP; our customers were also asking for it to be resizable. We addressed both of these by working closely with Tablet developers to share a common code base between the Tablet Soft Keyboard and the On-Screen Keyboard. Both keyboards now have an attractive appearance that is in tune with Windows 7 and both are now resizable. The keyboards still are distinct, though, because customers use them differently: Tablet users may want to switch dynamically between handwriting and typing, whereas On-Screen Keyboard users may need modes where they can hover or scan to keys, if they have disabilities that prevent them from clicking. Along these lines, we also added basic text prediction to help customers with disabilities enter text more quickly. If you have ever tried typing with an on-screen keyboard, you can appreciate how significantly text prediction can improve text entry speed.
The Magnifier came in for a deeper overhaul. The Magnifier in Windows Vista and Windows XP was not an intuitive experience: when you pointed at part of the screen, the magnified content appeared in a separate window, usually docked at top of the screen. You had to point at one place and look at another. We considered two basic solutions to this problem: you could zoom into the entire screen or you could make the magnified area follow the pointer while leaving the rest of the screen the same. These became our two primary modes for the Windows 7 Magnifier: Full-screen mode and Lens mode.
Full-screen mode is great when you want to increase the size of everything on the screen at once. As you move the mouse or keyboard focus around the middle of the screen, the view stays still; if you move towards the edge, the Magnifier scrolls the view to keep up. One downside of this mode is that you can lose track of your context. To address that usability issue, we added a context animation that zooms out to show you where your work area is relative to the whole screen, and then zooms back in.
Lens mode, on the other hand, is nice when you just want to zoom in on one particular thing. In this mode, the lens centers on the mouse pointer, which feels much like using a magnifying glass. You can re-size the lens to be very wide and short, which can be nice if you are reading a document and want to magnify it line by line. We based our design on the popular Microsoft IntelliPoint magnifier, a design you can now enjoy with any mouse.
We also addressed customer feedback about the Magnifier window taking up too much space on the screen. We moved the most commonly used controls like zoom in/out to a small toolbar, which fades out to a semi-transparent watermark when you aren’t using it. The remaining options are available in an Options dialog when you need them. Last, we gave almost everything a keyboard shortcut, so if you really don’t want to see the UI, you don’t have to use it. Win-+ will zoom you in any time you are using Windows 7.
These tools directly improve Accessibility for customers with low vision and dexterity disabilities. It should be obvious, but making the PC easier to see or interact with benefits everyone and so these two examples also show the broad appeal of AT tools – at the PDC we showed both the On-Screen Keyboard and the Magnifier and I think it is fair to see everyone saw the benefit of using these tools themselves, regardless of abilities.
Windows APIs cannot provide Accessibility all by themselves; it is vital for Windows-based applications to do their part in providing Accessibility data for AT programs to use. For example, a screen reader may sound excellent, but if it can’t read your favorite web browser, what good is that? Assistive tools like screen readers and magnifiers are clients of the Accessibility system, while the applications that you want to use, like web browsers and word processors, are providers. It takes both to make the whole experience accessible--you need both a high-quality client and a well-written provider to have a good Accessible experience. There are more providers in the software ecosystem, so it is hard for us to work one-on-one with every provider to make sure they are well-written.
To address this challenge, our team developed the UI Accessibility Checker (AccChecker for short) and UI Automation Verify (UIA Verify) utilities, which can scan an application (a provider, really) and report on common Accessibility problems. Software developers can use AccChecker and UIA Verify to detect problems in their provider code before a customer ever uses it. Quality assurance engineers can use them to verify the quality of their firm’s work. We believe this is so important that we released AccChecker and UIA Verify as open-source software to make it available to the widest possible audience. If you are not a programmer, you may never use these utilities directly, but you may well benefit from the bugs they helped to eliminate before they ever reached you.
To make sure that Windows features themselves were good providers, we borrowed an idea from the Software Development Lifecycle, risk assessment. Before a line of code was written, each planned Windows 7 feature was rated on its Accessibility risk. Features that use more basic, off-the-shelf common controls are usually more accessible because Windows provides built-in providers for off-the-shelf components; features that do fancy, custom drawing have more work to do. This planning process made each team aware of how much accessibility risk it was taking on, so that they could plan appropriately. Once the features were all rated, the list was sorted by risk so that our team could reach out to teams with high-risk features and make sure that they had the resources and tools they needed to make their feature properly accessible. We also ensured that they received more hands-on testing and validation. As a result, most Windows features are more accessible than they have been in previous releases, making for a better overall customer experience.
To wrap up, we've emphasized Accessibility in engineering Windows 7. We’ve made good progress on improving the core architecture for Accessibility and enhancing the included tools like On-Screen Keyboard and Magnifier. The AccChecker and UIA Verify tools have made it much easier to validate applications to ensure that they will be compatible with current assistive tools as well as future tools based on the Windows Automation API. Our approach to Accessibility for the features and providers in Windows itself has become more thorough, consistent and integrated, thanks to the hard work of hundreds of engineers across the company. We’re proud of what we have accomplished in Windows 7 and hope that it will help customers with disabilities to realize their full potential and have a more enjoyable experience with Windows.
indeed the team is on "vacation" :-)
Merry Christmas and Happy New Year to ALL!!
snavenÀ You can edit your whole start menu yourself, although some change could be made to improve the UI used to do this I managed to get mine with a lots of shortcuts that are very useful, here is a screenshot: http://img213.imageshack.us/my.php?image=33195172se4.jpg
bluefisch200> Totally agree, Aeropeek should be use too for alt-tab windowsswitching, I hate the mouse.
Since 1998 I'm the editor of magnifiers.org and the community there is exited about full-screen magnification in Windows 7 as mentioned in this Blog.
But in the latest beta, there is no screen magnifier with full-screen and lens mode at all!
Only the help files are suggesting, that there is a screen magnifier with full-screen and lenz mode, but the magnifier itself does not support this features?
The worst part of accessibility in Vista is navigating around through directories. You used to be able to use the arrow keys, return, and backspace to navigate around arbitrarily through the folder structure. Now backspace is "back" which breaks this behavior when working through shortcuts, and choosing an arbitrary folder above to click on is slow and tedious. The old up-arrow button (which does something) was replaced by a "refresh" button which does nothing, and placed in a prime spot of screen real-estate.
Get rid of the damn green button, and bring back up-arrow.
Here are some comments on Windows 7 accessibility, now that I've had a chance to try the beta (build 7000). I'll keep them in two separate posts for coherence.
1. Narrator: A lot has been said about changes to the OnScreen Keyboard and Magnifier, but Narrator is being neglected - and it's in need of some serious help. Back in Windows XP, even better in Windows 2000, Narrator was quite useful for its purpose. Then Vista came and Narrator took a huge downgrade. Despite the nicer voice of Microsoft Anna, Narrator in Vista is noticeably less responsive than Narrator on Windows 2000 or XP, and it isn't Anna adding the extra weight. I've tested Narrator in Vista with other speech engines, including the open source eSpeak, which is extremely responsive, except in Narrator. No matter what speech engine you use, Narrator takes forever to read menu lists or items as you move with the arrow keys, making browsing through lists unbearable. Not to mention the extra time it takes to announce "Down arrow", which is extremely annoying - maybe that's why respectable screen readers like JAWS or WindowEyes don't announce arrow keys and stick with announcing what control or list item you have landed, which is what you really want to hear. Please, please, PLEASE make Narrator in Windows 7 responsible and usable again, as it was in Windows 2000 or XP!
On a separate, but not totally unrelated note, I also agree that a Safe Mode option with basic sound support is really needed so blind users can troubleshoot their own systems.
After commenting on Narrator, here is my second comment on Accessibility in Windows 7 beta build 7000.
The Magnifier. It was nice to see Microsoft's Magnifier enlarging in full screen mode; this is something that should've happened back in Windows 98 or Windows 2000 at the very least. But the Magnifier in Windows 7 really misses the point.
1. Tracking UI controls and typing focus is annoying. That "smooth scroll" effect leads to some violent screen jumps that can make you dizzy.
2. The new Magnifier only works with Aero enabled. Why??? Although disabling Aero is yet another gripe I'll discuss in the next post, the truth is that once you start a full-feature screen reader, Aero gets automatically disabled. Kiss goodbye to the idea of using the Windows 7 Magnifier together with a screen reader such as WindowEyes or JAWS; you get the old-fashioned Vista magnifier instead. The only way to use MS Magnifier is if it is the only accessibility tool used. (Well, it works with Narrator, but Narrator really doesn't work - see my previous post.)
This is the last one of these posts, I promise, until things change for either better or for worse.
Themes: Unless you can survive with the built-in accessibility tools, your theme options are extremely limited. Back in Vista, Microsoft designed the system so that when a mirror driver (used by full-featured AT tools) is loaded, Aero goes away and you are downgraded to the extremely depressing and hard-to-use Vista Basic theme. From all the themes I've ever seen used in any OS, Vista Basic has to be the worst of the worst, not only in how ugly it is but also in the extremely poor contrast it has - you can hardly see when a menu item is highlighted, for example. Some of you might think "oh, blind people don't care about the theme." That's like saying a blind person doesn't have to dress fly or look good. While it's true appearance is not in most blind people's priorities, it isn't necessarily out of their list. I'll give you that one though, but remember, low-vision users can see the Vista Basic theme (just renamed "Windows 7 Basic" now) and suffer with the ugly it is and the low-contrast it provides.
What are our options? According to Microsoft, just switch back to the way outdated Windows 95-ish themes. I think Microsoft should've designed their accessibility so other AT programs can work with Aero. Or at the very least, provide updated themes options that are more usable and visually-appealing than the "basic" theme that replaces Aero when you need to use a fully-feature screen magnifier and/or reader.
For those of us who navigate by keyboard and voice, the search box in the start menu is a NUISANCE. I can't just press the Windows key+a letter, or say an item; I have to get the focus out of the search box first. It is clumsy and tedious. Have an option to turn the thing off, PLEASE!
I am a blind user using jAWS for windows, and very soon I am going to test out windows 7 64 bit with JFW 64 bit. there are some hardware issues I have to resolve, and a friend has to burn the dvd first, since the only dvd writer I have is on the new computer that has no OS installed.
So since to my knowledge there is no way for me to install windows 7 without sighted assistance, nno way of using a script or any other silent installation, I will have to both find a screen, and a sighted person who is willing to use 30 to 60 minutes I hope before Narator or JAWS is up and running.
I am sure that many blind users like me is frustrated over this serious lack of accessability! especially when users of voiceover the screen reader for mac has all the advanced possibility. voiceover can be started on any mac running 10.4 or later, no special installation. Voiceover can both do roleback and an OS reinstall something no screen reader, narator, or JAWS or any other windows screen reader is able to do. I understand that the scope of the accessability features also in windows 7 is limitted seen from a blind users perspective compared to mac users, so a way to do installs without sighted help is for me at least very very important. yes it is nice that 7 runs faster even on slow hardware, and all the visual changes are of no practical use, so I think many blind users will look at important practical features like beeing able to manage the system or help on frends computers without sighted help!
About Magnifier in Window 7, I am wondering if I can run it with some CMD
command like "Magnify.exe -lens/fullscreen -somerate"?
since I used msdos, I have been using windows products. I was interested in eachimprovement of windows. but I cant say samethig
for windows 7 . I cant adopt windows 7.
The accessibility options in Windows 7 are WORSE than they were in Windows XP, and they were not very good in Windows XP! It seems like no one in your team has made use of them for any significant period of time because of their poor design. I will admit that they are significantly better than on a Mac, but they contain some serious design flaws. I depend on the Sticky Keys and Mouse Keys on a daily basis for 8 to 15 hours per day, and have to keep on reminding myself that at least they are better than those on a Mac!
Here are my problems:
1) Windows 7 IGNORES the BIOS. My BIOS tells Windows 7 to TURN OFF the Num Lock, but if Num Lock was on when I shut down my computer it TURNS ON when I turn on my computer! I wrote a program which changes the Num Lock setting, but changing the Num Lock setting has no impact on Mouse Keys. I have looked through the registry and the system files but I am unable to figure out how to progmatically turn on Mouse Keys.
2) Windows 7 occasionally is neglegent in its duties to turn on Mouse Keys. Instead of hitting Num Lock once to turn on Mouse Keys I have to hit it thrice. Now do not tell me that I am not using enough force, because the status of the Num Lock key changes each time I hit this key.
As I was writing the problems I was having with the accessibility options it suddenly became apparent why I had had so many problems with them in Windows XP: 1) I had neglected to clear the check box labelled: Turn on Toggle Keys by holding down the NUM LOCK key for 5 seconds. I had assumed that I did not need to clear this check box since I had already turned on this feature. In reality the label of this check box should read: Toggle the Toggle Keys Feature by holding down the NUM LOCK key for 5 seconds. 2) I had unwittingly assumed that by not setting the check box labelled 'Turn on Filter Keys' that this option would not be available, but Windows sets the toggle switch for this option by default. The label of this check box should read: Filter Keys has been Set by Default. Activate It when Windows Boots.
What is really frustrating me in Windows 7 is the lack of visibility on the selected menu item. This only uses a very thin line of cyan colour which does no contrast well at all.
I do not want to switch to the classic Windows style, this is a retro step.
Pls pls allow some customisation in this area.
Is there an equivalent, "Linux AccessX" like software that is compatible with Windows 7?
This software will need to have a persistent display and control GUI on the display in order to view and control mouse status.
You may get an Idea of the Accessx software particulars at the following website:http://cita.disability.uiuc.edu/software/accessx/links.php