Boost Your Design with Microsoft’s Inclusive Visual Studio Code

Universal, or inclusive design is a new design philosophy Microsoft seems to take quite seriously in software development recently. Inclusive design takes accessible design to the next level, as it views accessibility from a much broader perspective. When I was testing Microsoft’s new source code editor, Visual Studio Code, the question of how they implemented the theory in practice naturally arose in my mind.

This post doesn’t intend to be solely a description of Visual Studio Code’s accessibility features, as in the official docs you can find a great recap of them, but rather aims to be a case study on what to pay attention to when you want to design an inclusive app in the future.

Because we can be sure that inclusivity will soon be a requirement in both software and web design, of course not only for altruistic reasons, but because it will bring many new users to the table.

Microsoft’s 4 Principles of Inclusive Design

Windows Dev Center puts accessible software design inside the Usability category, and they also published many great articles on the topic. Microsoft’s four principles of inclusive design (listed briefly below) are discussed in this article.

1. Think universal.
2. Make it personal.
3. Keep it simple.
4. Create delight.

If you’ve read through the original article, you will see the principles are explained in a way that’s not always easy to test, using expressions like "emotional connection", "evoke wonder", and "magical". So I’d rather stay down-to-earth, remove these subjective connotations, and turn the principles into objective criteria.

When I analyze how they are implemented in Visual Studio Code, I use them in the following sense:

1. Think universal: Accessibility
2. Make it personal: Customizability, extensibility
3. Keep it simple: Distraction-free, logical user interface
4. Create delight: Feature discoverability

Of course, this is just one possible categorization, and there are many overlaps, for instance customizability can also be part of the “Create delight” principle, but as we need something tangible, let’s stick to this interpretation for now.

While Windows Dev Center recommends these inclusive design principles to be applied for Windows 10 apps, Microsoft also dedicated its Microsoft Design site to inclusive design.

Although Visual Studio Code is not solely for Windows 10 but aimed to be a cross-platform software, we can still safely test its features against the aforementioned principles, as Microsoft clearly treats inclusive design as the software design path they want to follow in the future.

1st Principle: Think Universal

Under the “Think Universal” principle, we’ll scrutinize how accessible Visual Studio Code is for diverse user groups, such as users of assistive technologies (whether they use them for disabilities or preference), people with limited technologies, non-native English speakers, etc.

1. Zoom

Zoom can be easily performed by hitting the Ctrl + = / Cmd + = (Mac) keyboard shortcut for Zoom In, and the Ctrl + – / Cmd + – (Mac) shortcut for Zoom Out, and we can also access the Zoom feature via the top menu bar.

Note, that as of the version 1.1.1, on Windows keyboards the + and – signs doesn’t work on the numeric keypad on the right, only on the typing (alphanumeric) keypad – which probably isn’t the best for inclusivity.

The Persisted Zoom Level feature somewhat compensates for this, as it allows us to easily configure a persistent Zoom level in the User Settings (read my pervious post on how to do this).

2. High Contrast Theme

High contrast themes facilitate in processing visual information for visually impaired users, and therefore they are an important element of accessibility.

There’s a default High Contrast theme in Visual Studio Code, that you can set by clicking on the File > Preferences > Color Theme menu, but you can download others from the Visual Studio Code Marketplace as well.

Microsoft introduced High Contrast themes in Windows 7, it’s nice to see that they follow through with this feature.

3. Keyboard Navigation

Providing keyboard navigation is essential for people who can’t use the mouse because of visual or mobility disabilities. Effective keyboard navigation entails that users can control every functionality of a software by using only the keyboard.

Visual Studio Code nicely implements this feature, and while it has many preset key bindings (see the full list), users can also customize keyboard shortcuts with the help of a JSON-format configuration file.

4. Tab Navigation

Tab navigation makes it possible to jump all over the different areas of Visual Studio Code.

Currently, as of version 1.1.1, VS Code doesn’t support tab navigation for all areas, for example the top menu bar is not available this way. The good news is Microsoft acknowledges the lack of this feature in the Current Known Issues in the docs.

During the testing, I found that the Editor, the Side Bar, the View Bar (see the naming of VS Code’s areas), and all of their actions and items are accessible with the Tab key. Although Tab users can’t access the functionalities of the top menu bar with their keyboard. The Command Palette F1 can somewhat substitute for this, as all commands that can be found in the top menu can be accessed from there as well.

An important accessibility feature of tab navigation is tab trapping which enables users to switch between the two functionalities of the Tab key. The trapped Tab key makes it possible to move across the different parts of VS Code, while normally the Tab key adds a Tab character to the text file open in the Editor area. Users can switch between the two capabilities by hitting the Ctrl + M key binding.

5. Screen Readers

Of course, an accessible software needs to be fully available for screen reader users as well. The docs mention that the VS Code dev team tested screen reader availability with the NVDA screen reader.

For testing, I used two other screen readers, JAWS that is one of the most widely used screen reading apps, and Microsoft Narrator that is Windows 10’s built-in screen reader.

JAWS read aloud all areas, commands and menus diligently, however Narrator had some smaller issues with the task. For instance, it only read the top menu items properly when I moved across them with the mouse, but not when I used the Down arrow on my keyboard. This, however, is rather a shortcoming of Narrator, not Visual Studio Code, so we can safely assume that visually impaired users can access all VS Code functionalities by using a more advanced screen reader app.

6. Debugger Accessibility

To make an app fully accessible and inclusive, we also need to take care about parts that probably don’t come at first to our mind. In case of Visual Studio Code, the Debugger is a good example for this. The dev team paid attention to make it inclusive as well, therefore it also supports Tab and keyboard navigation, and it’s screen reader accessible.

7. Localization

Now we are ready with discussing the accessibility features VS Code lists in the docs, but there are other important things as well we need to mention when we speak about the “Think Universal” inclusive design principle. One of these is localization, or with other words support for foreign languages as display language, as many people in the world are not native English speakers.

Visual Studio Code is currently localized for 10 different display languages (English, Simplified Chinese, Traditional Chinese, French, German, Italian, Japanese, Korean, Russian, Spanish).

Users coming from these languages don’t even have to configure their display language, as VS Code picks up the display language of the operating system by default. If they want to set another language as display language, they can easily configure their locale.json file.

Probably 10 display languages are not that many, but it’s also not bad if we take into consideration that VS Code is a new software, and Microsoft will most likely support more in the future. For now, users whose language is not among the supported ones get their VS Code installed in English.

8. Accessible Size

Modern source code editors are not really large, and Microsoft has also joined this trend, as Visual Studio Code is a less than 100 MB download, and its disk footprint is less than 200 MB.

9. Cross-Platform Development

If we want inclusive software, of course it also need to be cross-platform that means it needs to run on different operating systems. VS Code meets this requirement, as it supports Windows, OS X and Linux as well.

2nd Principle: Make It Personal

“Make It Personal” is Microsoft’s second principle of inclusive design, and we’ll have a look at customizability and extensibility under this criterion, as I promised it before. Visual Studio Code meets both requirements so nicely that I even wrote separate posts on both of them, here on customizability, and here on extensibility.

In short, customizability is implemented with custom themes and modularized JSON-format configuration settings, while extensibility is achieved by custom extensions that users can download from the Visual Studio Code Marketplace, or create their own in either TypeScript or JavaScript.

You can read more on the technical background of Visual Studio Code’s approach to extensibility here.

Customizability is solved in a way that’s ideal to tech-savvy people who are the typical users of source code editors, as a significant part of it is implemented via modularized JSON-format configuration files.

This is a great solution, as the configuration options are not hidden behind a huge menu hierarchy that’s hard to see through. Users, even if they are not coding experts, can easily edit their custom .json files, as Visual Studio Code opens the default and the custom settings in two editor panes right next to each other, allowing users to easily experiment with them.

Configuration files are modularized, they come as a logically structured hierarchy of .json files, here’s a list of the most important ones:

1. settings.json for custom User Settings, accessible via the File > Preferences > User Settings menu
2. .vscode/settings.json for custom Workspace Settings, accessible via the File > Preferences > Workpraces Settings menu
3. keybindings.json for custom Key Bindings, accessible via the File > Preferences > Keyboard Shortcuts menu
4. javascript.json, php.json, css.json, c.json, and a bunch of other .json files for different programming languages for setting up custom User Snippets, accessible via the File > Preferences > User Snippets menu
5. launch.json for custom Debugger Settings, accessible by clicking on the gear icon on Debug View’s top bar (on the left of the editor)
6. .vscode/locale.json for custom Display Language settings, accessible by typing the Configure Language command into the Command Palette (F1)
7. .vscode/tasks.json for custom Task Runner Settings, accessible by typing the Configure Task Runner command into the Command Palette (F1)

I think VS Code users can hardly complain about customizability, as even listing the options was an exhaustive task.

As configuration options are modularized, users only have to take care of those they really need, which helps them keep focused on the tasks they want to perform. Thus, they will be left with a more intuitive workflow.

3rd Principle: Keep It Simple

We can meet Microsoft’s Keep It Simple inclusive design principle in many other places in programming and design, just think about the KISS (Keep It Simple, Stupid) design principle, and the DRY (Don’t Repeat Yourself) software development principle. For this running context, we’ll keep our focus on the simplicity of the user interface.

In terms of accessibility, an easy-to-use, simple user interface is usually recommended because of users who have cognitive and intellectual disabilities. Since Visual Studio Code is a source code editor, it’s probably not a software that’s frequently used by people who have this kind of impairment, however there may be some grey areas as well.

Simplicity is not only important because of them though, as a well-designed, logical interface can also lower the learning curve, and increase the speed of work, making a software more appealing to the general population as well.

Visual Studio Code also leverages the well-known psyhological phenomenon, the mere-exposure effect (or familiarity phenomenon), as it adopts a basic layout that’s similar to the layout other well-known source code editors, such as Atom, use.

From the docs we can get to know that it was an endeavour Microsoft put a huge impact on:

"Like many other code editors, VS Code adopts a common user interface and layout of an explorer on the left, showing all of the files and folders you have access to, and an editor on the right, showing the content of the files you have opened."

VS Code also provides users with the Side by Side Editing feature that can also be found in other source code editors, and it’s not a coincidence, as it makes the coding process much simpler, and of course contributes to the “Keep It Simple” inclusive design principle, too.

On top of the basic UI, Visual Studio Code has cool features that’s worth mentioning in an article about inclusive design, such as:

• Intellisense that provides users with suggestions based on context (the backend part that uses artificial intelligence is also a nice solution)
• Peek (Shift + F12) that displays complete function definitions in an inline window
• Command Palette (F1) that makes all commands accessible at the same place.

4th principle: Create Delight

It’s not especially easy to find tangible criteria we can use to examine the “Create Delight” inclusive design principle, so I finally settled for the criterion of feature discoverability, as Microsoft defined this principle the following way:

"Delightful experiences evoke wonder and discovery. Sometimes it’s magical. Sometimes it’s a detail that’s just right. We design these moments to feel like a welcomed change in tempo. The result is an experience that has momentum and flow."

This phrasing may remind many of you of micro-moments, one of Google’s latest big thing, and therefore show how leading technology companies may come to similar conclusions when they think about how to move the industry forward.

In inclusive design, it’s very important to engage users, and arouse their curiosity, that we can achieve probably the best if we help them move forward when they reached a certain point in their user journey. Just in the right moment, not before, not after.

When we speak about feature discoverability, the more worldly manifestation of creating delight, it can be increased by things like well-designed utility navigation, smart documentation, and supportive information that pops up only in the right moment.

We can find examples for all of these features in Visual Studio Code, just think about the aforementioned IntelliSense and Command Palette, but syntax highlighting and custom code snippets can also help users to make the most of the software. You need to judge for yourself whether using Visual Studio Code leaves you with the feeling of delight.

For myself, I more or less liked the experience: the well-structured online documentation, the easy-to-navigate Visual Studio Code Marketplace, and the custom colour themes that can be previewed real-time while scrolling a drop-down list (access it via the File > Preferences > Color Theme menu).

Final Words

As inclusive design is a new field, the technology industry is still at the experimentation phase. I think Microsoft made a significant milestone by defining the four principles of inclusive design.

As we could have seen, they managed to successfully implement the theory in practice in their new source code editor, Visual Studio Code, although there are still some fields to improve, such as providing full Tab support and a global Search and Replace feature.

As both accessibility and inclusivity are parts of user experience, it can be a good idea to learn more about them if you want to keep up with the latest industry trends. Here are resources that may help:

• Windows Dev Center’s accessibility articles
• Microsoft Design’s Inclusive Design Toolkit manual (PDF) (downloadable)