Engineering Windows 7

Welcome to our blog dedicated to the engineering of Microsoft Windows 7

Accessibility in Windows 7

Accessibility in Windows 7

  • Comments 65

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 --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.

I. Build a firm foundation with UI Automation

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.

II. Improve our included Accessibility utilities

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.

III. Make it easier to build Accessible software

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. 

IV. Plan for Accessibility from Day 1

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.


Leave a Comment
  • Please add 4 and 5 and type the answer here:
  • Post
  • >>Vista hasn't been received well by market, because system has got some disadvantages.

    ...which have absolutely nothing to do with accessibility.


    I'm not particularly blind but I make regular use out of 6801's screen magnification, it works but text reproduction at some (most) levels of magnification is horrid. At 125% (and many other levels) some lines of text look slightly compressed (making them slightly difficult to read), have rainbow edges, and are otherwise in dire need of anti-aliasing. These effect sometimes make text somewhat harder to read zoomed. And giving me headaches, I think, which was plenty of reason for me to sadly put it down. DirectWrite and Direct2D are coming in the beta, I assume. Is it safe to also assume they will aid magnification? And will the magnification tool move to tracking the mouse rather than having to be dragged by moving to the edge of the screen? Dragging the view from the edge of the screen feels unnatural and I find it to be imprecise (not too big a deal) and difficult to use.

    And how will Windows 7 handle high-contrast mode and magnification? As things currently stand it's impossible to use the new magnification tool with high-contrast because WDM isn't running. The new magnification tool has to be used with Aero, which I imagine is bad for people that required high-contrast.

    And a suggestion: map magnification to Win+Scroll Wheel as well as the keyboard, using slightly  smaller incriments to better utilize smooth scrolling on some mouse wheels.

    And, of course, I should again mention these are the opinions of a person with no real _necessity_ for the tools. My eyesite is terrible but I can see with my trusty-dusty glasses, these just help.

  • @Vistaline

    >>Vista hasn't been received well by market, because system has got some disadvantages.

    ...which have absolutely nothing to do with accessibility.

    it has actually everything to do with accessibility, that type of blanket denial is what happened in the beta's of Vista. Vistaline were you part of the Vista betas? I know I was.  All Microsoft could say was no, go over to IE 8's blog, all Microsoft is saying is no. Microsoft is really not open to suggestions, and for the life of me I can't figure out why. There are many reasons why Vista has failed, but first and foremost is, they dismissed user feed back as just reluctance to change, that they knew better. Microsoft lost, the industry lost, they need to learn from their mistakes, they need to listen even if it is not what they want or the majority wants. What it comes down to is options, Microsoft need to stop dictating. They need to understand that just because they think it's a great idea, doesn't make it so. "Life with out Walls" is not just a marketing ploy, its a philosophy that Microsoft needs.  

    "Those who ignore history are doomed to repeat it."

     --George Santayana    

  • Does the full screen magnification work like the commercial products (ZoomText, ZoomWare and MAGic)?  In other words, does it transparently magnify the screen so that your cursor still operates icons and applications as if the magnification was not there?

    I am looking forward to obtaining the beta - and I do not get to go to CES or the developers conferences :(  and trying out the features.  I have clients who just need basic screenreading and magnification in their lives, NOT the full power (yet) of the commercial products.

  • Team is in Holiday?

    Pls new thread :D

  • @AssistiveTech

    Yes like its how you look just on a little part of the screen...


    Also waiting^^

  • Hey Folks,

    Product is great. However I found an issue that should be addressed before beta1 gets released to the masses.  Don't know if anybody tried to innstall the latest build in a dual boot situation with Windows Vista, but there is a boot screen malfunction. The "Animated" bootscreen that everyone is "ga-ga" to get in beta 1, is in conflict with Vista's Boot manager. It seems to go to the default bootscreen instead of the new animated one. I was diappointed when it didn't work for me. Now imagine me x 100,000. I tried all kinds of thing including deleting the bootmanager, and installing windows 7 bootmanager. Still no love! Aanyways, please pass this to the proper channels to fix .

    This occus on both x86, an x64 platforms.



  • @FireRx

    Hey you have a bad dump from VHD , wait Beta.

    @ Team Windows

    Remember  this Beta will pass into the hands of journalists bad who will try in every way to create negative reviews

    PLS  Unleash Hell.

    - Domenico

  • I saw @ WinHEC that if you hover the mouse over a live preview, you see the window in full size. Wy dont add this feature to the [Alt] - [TAB] window switching?

  • + If i have a window minimized in Vista and also in PreBeta of 7(6801) the live preview do not update and you see always the old preview. I hope you will change that for the Beta...

  • @bluefisch200

    You wont Update PrePreBeta? Noo :D

  • Still using 6801.  Some minor issues, but still a darn sight better than Vista was (not a hard goal to achieve, mind..)

    I am hoping the problems of Vista are gone now that you guys have changed the dev process.  It seems to be working so far.  

    Keep it up guys... and get on with the next post already!  :D

  • @PsironTech

    were is a problem in Vista?

    Fud or problem?

  • No problem in Vista if you know how to manage. i think W7 is much more productiv and more easy to work with it.

    so i belive problems in Vista is fud.

  • @Domenico:

    Personal experience?

    Wireless resets, inconsistent USB file transfer speeds, incredibly slow UI response time, slow boot, slow shutdown, power management not functioning properly - no sleep/hibernate).

    It's a far sight better than it was pre SP1, but it's no-where near stable on any of my personal systems.  Both of them fare much better on XP or Win7 (though Win7 seems to still have issues with USB at this point).

    Drivers have gotten much better. It's _almost_ usable now, but what's the point?  Especially since it looks like a July 1 RTM for Win7.

    No FUD.  Just personal experience.  I can put XP or Win7 on either of the two laptops and have a quick, responsive, stable system.  Putting Vista on them ... Not so much.

    Really, the wireless issues are the worst though.  Sure, it could be my router+Vista=problems, but since the router works flawlessly with XP and Win7, why fight it?


    If it works for you, great!  But don't tell me I don't know how to manage my systems just because it works for you/not me.  Talk about ego tripping...  I've been doing Enterprise IT for 12 years now.  We're skipping Vista (though had it looked like Win7 would have been delayed anywhere near as much as Vista, we'd have gone to it for the security benefits alone and made due with the other issues).

    @ devs:

    Keep up the good work, guys.  Can't wait for Beta 1!

  • I just took a look on the Task Bar in 6956. It looked a kinda nice, but you've done some terrible mistakes there.

    Where is the "Network" shortcut in the Start Menu??? I use all the time. I need it!!!

    It's very annoying that the Internet shortcut no longer are in the Start Menu (exept "all programs").

    Also I would like to have the Run command available.

    Please listen to this. You should not make to many differences in Windows 7. Good Luck! Can't wait to get a Beta key to Windows 7!

Page 3 of 5 (65 items) 12345