18 May 2018
18 May 2018

A new product badge for Microsoft Store applications

Author: Eric Langland
Go to Source

Applications with new web badge for Microsoft Store products.

As many of you know, building quality apps is quite a commitment and investment in time. Once your app is in the Store, the next challenge is getting the word out about your new title and driving traffic to your product. Today, we’d like to announce a new tool for marketing your apps in your own blogs and websites. We’d like to introduce our new web badge for Microsoft Store products.

8 Zip application

The new badge will render in your own website pulling localized logo, pricing (including sale pricing!), ratings and artwork directly from the store catalog. To render this badge for 8 Zip simply embed this script using its Store Id (9wzdncrfhwb8). Please note you must add the Id in two places in the badge script, the “class=” and inside the “mspb-“.


<div id="mspb-nc9jl2ngc1i" class="9wzdncrfhwb8"></div>
<script src="https://storebadge.azureedge.net/src/badge-1.6.1.js"></script>
<script>
mspb('9wzdncrfhwb8', function(badge) {
document.getElementById('mspb-nc9jl2ngc1i').innerHTML = badge;
});
</script>

The button click on the badge will direct your customers to the proper Product Description Page where they make the actual purchase. You can add multiple badges to any single page, just make sure they all use a unique div Id, as shown above.

To see the badge in action, check out XBOX’s @majornelson (www.majornelson.com) who is using the badge to promote Xbox content on his blog.

Example post here: https://majornelson.com/2018/05/03/xbox-live-gold-members-play-for-honor-xcom-2-and-just-cause-3-for-free-this-weekend/.

That’s it! Feel free to promote your apps and games on your own sites.

Go to Source

Share this
18 May 2018

Console UWP Applications and File-system Access

Author: Andrew Whitechapel
Go to Source

As announced in the May 2018 issue of MSDN Magazine, the latest Windows update introduces support for Console UWP apps. We’re also introducing support for UWP apps to get broader access to the file-system than was previously possible. In fact, it was during the design and development phases of the Console app support that we realized we’d need to provide these apps with better file-system access – so the two features complement each other nicely.

Console apps represent a significant departure from the “normal” UWP model. Specifically, these apps don’t have their own windows, and don’t use the familiar input mechanisms. One of the attractions of UWP is the rich UI support, which allows you to build beautiful, highly-interactive apps. Console apps, on the other hand, use the standard console window for input and output, and the model is very much command-line driven and plain-text-based.

So, yes, Console apps are very different from traditional UWP apps, and they meet the requirements of a rather different target audience. They’re aimed squarely at developers who need to build admin or developer tools. To help you get started, we published a set of Console App (Universal) Project Templates in the Visual Studio Marketplace.

Let’s walk through creating a very simple Console UWP app, just to explore the possibilities, and to examine some of the options you have in using UWP features. The finished app is an (extremely primitive) implementation of the classic findstr tool – the app is in the Store here, and the sources are in the AppModelSamples repo on GitHub here.

To create this app from scratch, in VS, having installed the project templates, select File | New Project, and then select one of the two C++ project types for Console UWP apps – either C++/CX or C++/WinRT. In this example, I’ll choose C++/WinRT:

Select one of the two C++ project types for Console UWP apps – either C++/CX or C++/WinRT

When prompted for the target platform version information, select a version that’s at least 17083 or later (including Windows Insider builds):

When prompted for the target platform version information, select a version that’s at least 17083 or later (including Windows Insider builds)

Two things to notice in the generated code. First, the Package.appxmanifest declares namespace aliases for desktop4 and iot2, and adds the SupportsMultipleInstances and Subystem attributes to both the Application node and the AppExecutionAlias node:


  <Applications>
    <Application Id="App"
      Executable="$targetnametoken$.exe"
      EntryPoint="MyFindstr.App"
      desktop4:Subsystem="console" 
      desktop4:SupportsMultipleInstances="true" 
      iot2:Subsystem="console" 
      iot2:SupportsMultipleInstances="true" 
      >
...
      
      <Extensions>
          <uap5:Extension 
            Category="windows.appExecutionAlias" 
            Executable="MyFindstr.exe" 
            EntryPoint="MyFindstr.App">
            <uap5:AppExecutionAlias 
              desktop4:Subsystem="console" iot2:Subsystem="console">
              <uap5:ExecutionAlias Alias="MyFindstr.exe" />
            </uap5:AppExecutionAlias>
          </uap5:Extension>
      </Extensions>
      
    </Application>
  </Applications>

From this it should be clear that in this release Console UWP apps are only supported on Desktop and IoT devices. Currently, only Desktop and IoT devices have consoles, so the feature only makes sense there.

The second thing to notice is the main function in Program.cpp. This simply gets hold of the command-line arguments and prints them out in a loop to the console.


int main()
{
    // You can get parsed command-line arguments from the CRT globals.
    wprintf(L"Parsed command-line arguments:n");
    for (int i = 0; i < __argc; i++)
    {
        wprintf(L"__argv[%d] = %Sn", i, __argv[i]);
    }

    wprintf(L"Press Enter to continue:");
    getchar();
}

You can press F5 at this point, just to get the app built and deployed, before changing anything.

The only command-line argument is __argv[0]

As expected, if you execute the app this way, the only command-line argument is __argv[0], which is the executable filename itself. Now that the app is deployed, you can also run it from its tile on the Start menu – and get the exact same results.

However, if you run a separate cmd (or Powershell) window, and execute the app from there, you can then provide any arbitrary command-line arguments you like. This works because installing the app also registered the AppExecutionAlias declared in the manifest. By default, this is set to the same as the project name, although you can of course change this, if you wish:

In contrast, you can also run a separate cmd (or Powershell) window

You can see from the standard generated code that you can use many of the traditional Win32 APIs – the latest Windows update adds a lot more console-specific APIs to the approved list, so that these can be used in Store-published apps.

But, what if you want to use WinRT APIs? Well, of course, this is a UWP app, so you’re free to use WinRT APIs also. This does come with a caveat, however. There are some WinRT APIs that assume that the caller is a regular UWP app with a regular window and view. A console app doesn’t have a regular window or view, so any window-specific APIs won’t work. For the more obvious window-related APIs, you should have no reason to call any of them since you don’t have your own windows, so the point should be moot.

For our simple findstr app, the first change is to add the broadFileSystemAccess restricted capability to the manifest. Add the namespace declaration at the top:


xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities" 
  IgnorableNamespaces="uap mp desktop4 iot2 rescap">

…and then the capability itself at the bottom:


<Capabilities>
    <Capability Name="internetClient" />
    <rescap:Capability Name="broadFileSystemAccess" />
  </Capabilities>

This corresponds to the File system setting under Privacy in the Settings app. This is where the user can enable or disable broad File-system access on either a per-app basis, or globally for all UWP apps:

File system setting under Privacy in the Settings app

Now for the meat of the app. The classic findstr tool is used to perform string searches in files. It has a lot of command-line options for configuring the search. Internally, it performs all the operations from scratch, using low-level Win32 APIs and without using any higher-level libraries. However, for the purposes of this demo, I’m going to cheat and use the std::regex APIs. One obvious reason for this is because I don’t want to write thousands of lines of code for this sample. A less obvious reason is that I want to explore how to use libraries of different types in my Console UWP app (more on this in a later post). My cut-down version of findstr will take in only two simple command-line arguments:

  • A pattern to search for.
  • A fully-qualified folder path, in which to search.

First, some housekeeping. I’ll add some #includes in my pch.h. I plan on using the Windows.Storage APIs as well as std::regex:


#include "winrt/Windows.Storage.h"
#include <regex>

At the top of my Program.cpp, I’ll add corresponding namespace declarations:


using namespace winrt;
using namespace winrt::Windows::Storage;
using namespace Windows::Foundation::Collections;

Now I can update main to get the search pattern and the starting folder supplied on the command-line. If for some reason I can’t open that folder using the Storage APIs, I’ll just bail with some suitable error code. This could be because the user has disabled File-system access in Settings, or because the folder path supplied was non-existent or badly-formed, and so on. Also note that I’m not doing any input-validation here – but of course in a real app you would be very careful to check all inputs before proceeding, and most especially if your app is expecting to have broad file-system access.


int main()
{
    hstring searchPattern = to_hstring(__argv[1]);
    hstring folderPath = to_hstring(__argv[2]);
    StorageFolder folder = nullptr;
    try
    {
        folder = StorageFolder::GetFolderFromPathAsync(folderPath.c_str()).get();
    }
    catch (...)
    {
        wprintf(L"Error: cannot access folder '%S'n", __argv[2]);
        return 2;
    }

If I did manage to get the folder open, I can then continue to use the Storage APIs to get all the files in this folder for searching, and then to call a recursive GetDirectories function, so that I can walk the folder tree from this point downwards. I’ll write the GetDirectories and SearchFile functions shortly.


    if (folder != nullptr)
    {
        wprintf(L"nSearching folder '%s' and below for pattern '%s'n", folder.Path().c_str(), searchPattern.c_str());
        try
        {
            IVectorView<StorageFolder> folders = folder.GetFoldersAsync().get();

            // Recurse sub-directories.
            GetDirectories(folders, searchPattern);

            // Get the files in this folder.
            IVectorView<StorageFile> files = folder.GetFilesAsync().get();
            for (uint32_t i = 0; i < files.Size(); i++)
            {
                StorageFile file = files.GetAt(i);
                SearchFile(file, searchPattern);
            }
        }
        catch (std::exception ex)
        {
            wprintf(L"Error: %Sn", ex.what());
            return 3;
        }
        catch (...)
        {
            wprintf(L"Error: unknownn");
            return 3;
        }
    }

    return 0;
}

Now for the recursive GetDirectories function. Given the collection of folders in the current directory, I can recursively process all sub-directories. At each level, I can also get all the files for searching.


void GetDirectories(IVectorView<StorageFolder> folders, hstring searchPattern)
{
    try
    {
        for (uint32_t i = 0; i < folders.Size(); i++)
        {
            StorageFolder folder = folders.GetAt(i);

            // Recurse this folder to get sub-folder info.
            IVectorView<StorageFolder> subDir = folder.GetFoldersAsync().get();
            if (subDir.Size() != 0)
            {
                GetDirectories(subDir, searchPattern);
            }

            // Get the files in this folder.
            IVectorView<StorageFile> files = folder.GetFilesAsync().get();
            for (uint32_t j = 0; j < files.Size(); j++)
            {
                StorageFile file = files.GetAt(j);
                SearchFile(file, searchPattern);
            }
        }
    }
    catch (std::exception ex)
    {
        wprintf(L"Error: %Sn", ex.what());
    }
    catch (...)
    {
        wprintf(L"Error: unknownn");
    }
}

Now, the SearchFile function. This is where I’m cheating and using std::regex instead of doing all the work myself. First, I’ll read all the text out of the file with ReadTextAsync. If the file isn’t a text file, this will throw an exception – for simplicity, I’m just reporting the error and moving on. Then, I enhance the raw search pattern to search for any whitespace-delimited “word” that contains the pattern. Finally, I use regex_search to do the pattern-matching, and print out all the found words and their position in the text:


void SearchFile(StorageFile file, hstring searchPattern)
{
    if (file != nullptr)
    {
        try
        {
            wprintf(L"nScanning file '%s'n", file.Path().c_str());
            hstring text = FileIO::ReadTextAsync(file).get();
            std::string sourceText = to_string(text);
            std::smatch match;
            std::string compositePattern = 
                "(S+s+){0}S*" + to_string(searchPattern) + "S*(s+S+){0}";
            std::regex expression(compositePattern);

            while (std::regex_search(sourceText, match, expression))
            {
                wprintf(L"%8d %Sn", match.position(), match[0].str().c_str());
                sourceText = match.suffix().str();
            }
        }
        catch (std::exception ex)
        {
            wprintf(L"Error: %Sn", ex.what());
        }
        catch (...)
        {
            wprintf(L"Error: cannot read text from file.n");
        }
    }
}

One additional convenience: because this is a UWP app, it will have an entry in the Start menu app-list, and the user could pin its tile to Start. So, if could be executed from Start – in which case, of course, it won’t have any command-line arguments. Given how I’m assuming the command-line includes at least a search pattern and folder path, I’ll allow for this with a simple check. So, I’ll add this right at the beginning of main:


    if (__argc < 3)
    {
        ShowUsage();
        return 1;
    }

…and define the matching ShowUsage function:


void ShowUsage()
{
    wprintf(L"Error: insufficient arguments.n");
    wprintf(L"Usage:n");
    wprintf(L"MyFindstr <search-pattern> <fully-qualified-folder-path>.n");
    wprintf(L"Example:n");
    wprintf(L"MyFindstr on D:Temp.n");

    wprintf(L"nPress Enter to continue:");
    getchar();
}

That’s it! Having re-deployed this version with F5, I can then execute it from a cmd or Powershell window, supplying a search pattern and a starting folder on the command-line:

Having re-deployed this version with F5, you can then execute it from a cmd or Powershell window, supplying a search pattern and a starting folder on the command-line

Now admittedly, my findstr app has only the most basic functionality, but hopefully it does illustrate how easy it is to create a simple Console UWP app that consumes both standard C++ library APIs and WinRT APIs.

For anyone who has already started experimenting with Console UWP apps, it’s worth calling out that the original version of the VS templates had a couple of bugs (or, arguably, a bug and an anomaly), which were fixed in version 1.4. The issues do not prevent the app from building and executing, but they do prevent F5 debugging and also correct packaging and store publication. If you have already created projects using the old templates, you can apply the fixes by making the same changes in the .vcxproj and package.appxmanifest files manually (for both C++/CX and C++/WinRT).

First, the bug. In the package.appxmanifest file, v1.4 added iot2 to the ignorable XML namespaces:


IgnorableNamespaces="uap mp uap5 iot2 desktop4">

Of course, if you’re not targeting IoT devices, then you can instead delete this, and also delete the IoT namespace declaration itself:


  xmlns:iot2="http://schemas.microsoft.com/appx/manifest/iot/windows10/2"

…as well as the iot2-scoped Subsystem declarations in both the Application and AppExecutionAlias nodes:


iot2:Subsystem="console"

Now for the anomaly: v1.3 of the template included declarations in the .vcxproj file that are specific to .NET Native. These are required if your app includes say a C# WinRT component, where .NET Native is used. However, if your app doesn’t include such a component then the declarations will prevent correct packaging. In v1.4 of the template, these have been removed – both the target framework declarations at the top of the file:


    <TargetFrameworkIdentifier>.NETCore</TargetFrameworkIdentifier>
    <TargetFrameworkVersion>v5.0</TargetFrameworkVersion>

…and also multiple instances of the following:


    <PlatformToolset>v141</PlatformToolset>
    <UseDotNetNativeToolchain>true</UseDotNetNativeToolchain>

Please also note that all C++/WinRT templates are still experimental at this stage, and subject to change.

Apologies for any inconvenience caused by the bugs – and please do let us know if you have any feedback on the templates, or on the Console UWP feature.

For documentation, see Create a Universal Windows Platform Console app and File access permissions.

Go to Source

Share this
18 May 2018

Glassmaker glassybaby streamlines retail scheduling and fosters communication with Office 365

Author: Guest Author
Go to Source

Today’s post was written by Lee Rhodes, founder of glassybaby in Seattle, Washington.

Profile picture of Lee Rhodes, founder of glassybaby in Seattle, Washington.I launched glassybaby in 1998 after being diagnosed with cancer and finding hope in the light of a handmade votive. At first, I started making votives and giving them away, but that evolved into a business. We call our votive a glassybaby because of its small round shape.

I made giving foundational to the company’s mission, and today, glassybaby donates 10 percent of all sales to a variety of charities dedicated to healing. That’s important to the people who work here. They’re passionate, mission-focused individuals who want their work lives to make a difference. They want to spend their time at work evangelizing the glassybaby mission, not struggling with administrative chores.

Our basic manufacturing process is very artisanal—handblown glass—and we’re not about to bring in machines to do that. It’s a point of pride that every one of our products is touched by human hands. But in other areas of our business, we’re trying to modernize with technology and are using Office 365 to help us do that.

Office 365 is such a broad offering; we put the apps out there and let employees take a self-service approach to finding the tools that meet their needs. We’re a fast-growing company of 400 people, so we don’t have time for lengthy product rollouts and training. We need tools that our employees intuitively understand so they can get themselves up and running.

These tools have been life-changing for us at glassybaby. We’re all in different locations on different schedules; the glassblowers work two shifts a day, the stores open at overlapping times, the corporate staff works from 8:00 AM to 6:00 PM. It’s changed our lives to have a place where we can all go and find information and communicate.

Not only do these tools help us be more efficient, but they’ve enabled more culture and community-building here at glassybaby, and that’s one of the byproducts that I’m really proud of.

I don’t think we could function without these tools; I can’t even imagine working today as we did three years ago. The Office 365 applications have really helped with the flow and the rhythm of glassybaby and alleviated a lot of stress.

—Lee Rhodes

Read the case study to learn more about how glassybaby is empowering its Firstline Workers with intuitive Office 365 scheduling.

The post Glassmaker glassybaby streamlines retail scheduling and fosters communication with Office 365 appeared first on Microsoft 365 Blog.

Go to Source

Share this
18 May 2018
17 May 2018
17 May 2018

Previewing support for same-site cookies in Microsoft Edge

Author: Microsoft Edge Team
Go to Source

Yesterday’s Windows Insider Preview build (build 17672) introduces support for the SameSite cookies standard in Microsoft Edge, ahead of a planned rollout in Microsoft Edge and Internet Explorer. Same-site cookies enable more protection for users against cross-site request forgery (CSRF) attacks.

Historically, sites such as example.com that make “cross-origin” requests to other domains such as microsoft.com have generally caused the browser to send microsoft.com’s cookies as part of the request. Normally, the user benefits by being able to reuse some state (e.g., login state) across sites no matter from where that request originated. Unfortunately, this can be abused, as in CSRF attacks. Same-site cookies are a valuable addition to the defense in depth against CSRF attacks.

Sites can now set the SameSite attribute on cookies of their choosing via the Set-Cookie header or by using the document.cookie JavaScript property, thus preventing the default browser behavior of sending cookies in cross-site requests either in all cross-site requests (via the “strict” value) or only in some less sensitive requests (via the “lax” value).

More specifically, if the strict attribute is specified for when a same-site cookie is set, it will not be sent for any cross-site request, which includes clicking on links from external sites. Since the logged-in state is stored as a SameSite=Strict cookie, when a user clicks such a link it will initially appear as if the user is not logged in.

On the other hand, if the lax attribute is specified for when a same-site cookie is set, it will not be sent for cross-origin sub-resource requests such as images. However, the SameSite=Lax cookies will be sent when navigating from an external site, such as when a link is clicked.

This feature is backwards compatible―that is, browsers that don’t support same-site cookies will safely ignore the additional attribute and will simply use the cookie as a regular cookie.

We continuously work to improve our support of standards towards a more interoperable web. Although same-site cookies is not yet a finalized standard at the Internet Engineering Task Force (IETF), we believe the feature is stable and compelling enough to warrant an early implementation as the standardization process progresses.

To broaden the security benefits of this feature, we plan to service Microsoft Edge and Internet Explorer 11 on the Windows 10 Creators Update and newer to support same-site cookies as well, allowing sites to rely on same-site cookies as a defense against CSRF and other related cross-site timing and cross-site information-leakage attacks.

— Ali Alabbas, Program Manager, Microsoft Edge
— Gabriel Montenegro, Program Manager, Windows Networking
— Brent Mills, Program Manager, Internet Explorer

Go to Source

Share this
16 May 2018

Announcing the Xbox Adaptive Controller for accessible gaming

Author: Elana Pidgeon
Go to Source

Here are some of the highlights from Phil’s post:

“We have been on a journey of inclusive design, which celebrates and draws inspiration from people who are often overlooked in the typical design process.

For gamers with limited mobility, finding controller solutions to fit their individual needs has been challenging. The solutions that exist today are often expensive, hard to find, or require significant technical skill to create. A number of individuals and organizations are creating custom solutions, but it has been often difficult for them to scale when most rigs need to be so personalized.

Joining the Xbox family of controllers and devices, the Xbox Adaptive Controller was created to address these challenges and remove barriers to gaming by being adaptable to more gamers’ needs.  It was developed in partnership with organizations around the world, including The AbleGamers Foundation, The Cerebral Palsy Foundation, Craig Hospital, SpecialEffect, and Warfighter Engaged. We worked closely with them and directly with gamers who have limited mobility to assist in our development.

Our goal was to make the device as adaptable as possible, so gamers can create a setup that works for them in a way that is plug-and-play, extensible, and affordable.  In addition to working with common adaptive switches that gamers with limited mobility may already own, it has two large buttons built in. These buttons can also be reprogrammed to act as any of the standard controller’s button inputs via the Xbox Accessories app.

To make the Xbox Adaptive Controller a viable solution for the widest possible range of gamers with limited mobility, we’ve worked closely with third-party manufacturers to support external inputs which can be plugged in to the new controller. 

At $99.99 USD and available exclusively through Microsoft Store, the Xbox Adaptive Controller will offer significant value over the customized alternatives that exist today. We’re looking forward to sharing more about the Xbox Adaptive Controller in a few weeks at E3. The Xbox Adaptive Controller will be launching later this year, and we’ll share more information soon about pre-order availability.”

To read the full post from Phil Spencer, head over to Xbox Wire, and learn more about accessibility at Microsoft here.

Go to Source

Share this
16 May 2018

Celebrating Global Accessibility Awareness Day

Author: Yusuf Mehdi
Go to Source

At Microsoft, we want to empower every person and every organization to achieve more. We deeply believe everyone should have the opportunity to reach their potential and we can help by empowering all people, regardless of their abilities. Global Accessibility Awareness Day gives us the chance to celebrate our differences and reflect on the ways in which we continue to strive to make Windows more accessible to everyone in their everyday life.

Windows for each of us.

Inclusion starts with embracing what makes each of us unique. And it’s this belief that drives our passion to create technology that reflects the diversity of our customers. We have teams dedicated to discovering ways to make technology more accessible, developing products such as the recently updated Narrator, a built-in screen reader that empowers people with low or no vision to navigate and use their computers. Narrator helps people who are blind or have a visual impairment to read the text that is displayed on the computer screen with a speech synthesizer or braille display.

This feature is invaluable to many of our customers, including Nori, who has had a visual impairment since birth. Narrator has helped her pursue her passion for Japanese culture and public speaking. She’s a fan of using it to prepare for Japanese oratory competitions (which she has won five years in a row!). We’re grateful to have Nori in our Windows Insider program—her insights help us continue to develop tools to reflect the diverse needs of our customers.

Nori

Windows adapts to you.

Windows is designed to adapt to you whether you have a disability, a personal preference, or a unique work style. There are simple ways to enhance Windows to make it easier for you to see, hear, use, and focus on what’s in front of you. Here are some of the accessibility features our Windows customers tell us they like the most:

1. Magnifier enlarges words and images with custom settings you can use on all or part of the screen.

Magnifier used in Excel

2. Color Filters enable you to boost contrast, or remove color entirely—whether you have colorblindness, light sensitivity, or a visual preference, you can customize your screen’s color palette.

Settings page showing Color Filters next to the filters used in Excel

3. High Contrast lets you increase the color contrast of text and images on your screen, making them easier to identify. Each high contrast theme can be customized to suit your needs and tastes.

Settings page showing High Contrast options

4. Narrator is a screen-reading app, offering simplified navigation and intelligent image description so you can easily explore a page without missing anything. Learn more about how someone who is blind uses a computer, as well as the team that works on making Windows more inclusive.

5. Learning tools in Microsoft Edge make it easier for people with dyslexia to consume written information. New built-in grammar tools break down syllables and highlight parts of speech, and the Read aloud feature works with ePubs, PDFs and websites.

Learning tools in Microsoft Edge

In my post about the new Windows 10 April 2018 Update, I talk about two of my own personal favorite features: Focus Assist and Dictation. These are great options for people who want to get things done without distractions or create more naturally with their voice. If you’d like to see some of these features in person, please join us at your local Microsoft Store for Ability Week, a five-day experience starting May 29 through June 2. We will be showcasing hearing, vision, mobility, and cognitive assistive technologies that empower people with accessibility needs.

We believe that when we build tools that empower each of us, we all will benefit. Thank you for joining us in supporting Global Accessibility Awareness Day.

Yusuf

Go to Source

Share this
16 May 2018

Reimagine accessibility and foster inclusion in the modern workplace

Author: Jeff Teper, Corporate Vice President for OneDrive, SharePoint, and Office
Go to Source

On May 17, 2018, Microsoft joins in marking the seventh Global Accessibility Awareness Day (GAAD), a day dedicated to raising awareness of accessibility in the digital world. In honor of this day, we are releasing a short film: Empower every person: reimagining accessibility.

This film features accessibility experts from Microsoft and our partners: US Business Leadership Network, Be. Accessible, TD Bank (Canada), and Rochester Institute of Technology. It introduces best practices to build more modern and inclusive workplace environments and how accessible-by-design technologies empower every person to create, communicate, and collaborate. It also showcases new capabilities in Microsoft 365 being unveiled today that make it easier to create accessible content.

As more people across the world join in marking this day and take actions every day to create a more accessible digital world, people of all abilities will be able to fully participate and contribute. More than one billion people need assistive products to be independent and productive, but only 1 in 10 have access. Delivering experiences that empower every person to achieve more is what energizes us at Microsoft to do our best work, and I invite everyone to bring that energy to making accessibility non-negotiable in their places of work and across the whole digital landscape.

I continue to be inspired by the ever-increasing number of organizations prioritizing accessibility, and collectively there has been clear progress. However, given adults with disabilities have twice the unemployment rate of those without, more progress is needed to enable the transformative change we all want. At Microsoft, we found that addressing accessibility requires attention in all stages of product development: design, implementation, and testing. Making things accessible from the get-go is not only affordable, but also beneficial for a broad set of people. Given this, our mainstream technologies—such as Microsoft 365—include built-in assistive technologies and accessibility features.

Empowering people with disabilities to create, consume, and share content in their preferred way is a key part of the Microsoft 365 vision for accessibility. In line with this vison, we created new Ease of Access settings in Windows 10 and built-in settings, such as Read Aloud and Dictate in Office 365. These capabilities are designed to support people with a range of access needs: vision, hearing, and interaction. For example, to make interactions more efficient for keyboard users, we have introduced text suggestions that suggest the top three words while typing in on-screen keyboards as well as hardware keyboards. Adoption metrics are a great indicator of product value. Three years ago, we introduced Learning Tools as an add-in to help the 1 in 5 people who exhibit signs of dyslexia. After embedding Learning Tools into mainstream Office 365 applications and the Microsoft Edge browser, we have over 10 million monthly active users. Inclusively designed tools are clearly beneficial for everyone, and I continue to be energized by the powerful stories of inclusion in action told by people whose lives are transformed through Learning Tools and other accessibility features built into Microsoft 365.

Diversity is a strength for any business, and diverse teams must be able to seamlessly collaborate. Another key part of the Microsoft 365 vision for accessibility is to empower everyone to create accessible content and provide equal access to information to people with disabilities such as blindness, low vision, or dyslexia. AI is already infused in Microsoft 365 to help with several aspects of image, audio, and video accessibility. With automatic alt-text for images in Word and PowerPoint, we give you a head start by providing descriptions for images recognizable by Computer Vision. The Presentation Translator add-in for PowerPoint enables you to display live subtitles in more than 60 languages. Additionally, Microsoft Stream generates automatic transcripts for videos in English and Spanish using AI to convert speech to text.

In the coming months, we will ship new features to Microsoft 365 that will make it even more efficient for everyone to create accessible content and ensure diverse teams can collaborate inclusively.

  • Accessibility Checker—Already discoverable next to Spelling Checker in several Office 365 PC and Mac applications, the Accessibility Checker will be enhanced to run proactively in the background. It will alert you in real-time of issues that make your content difficult for people with disabilities to access. For example, it will alert you of low-contrast text that is difficult to read because the font color is too similar to the background color.
  • MailTip—A MailTip will be offered in Outlook for PCs to remind those who collaborate with you to check the accessibility of their content if you indicate that you prefer accessible content, similar to the MailTip available in Outlook Web Access today.
  • Recommended Actions—A new Recommended Actions menu will be introduced within the Accessibility Checker to make it easier to fix flagged issues. It will recommend actions such as Add a description, Mark as decorative, and Suggest a description for me for a picture in a document that is missing alternative text.

This GIF shows the Accessibility Checker being run from the Review tab in a Word document with black text on a grey background and an image of a forest. Accessibility Checker inspection results show that the image is missing alternative text. To fix the issue, the user clicks the recommended action, Add a description, which opens the Alt Text pane. The user types the image description the text box. The user then clicks the Low-contrast text warning in the Accessibility Checker inspection results, and then clicks the recommended action and changes the page color to white. The inspection results now show no more accessibility issues.

We’re on a journey at Microsoft to design, build, and launch more accessible products to foster digital inclusion in the modern workplace. I invite you to join us on this journey as we reimagine accessibility. Visit the Microsoft accessibility site to learn more about our approach. Share your learnings with #ReimaginingAccessibility and continue the conversation with @MSFTEnable on Twitter.

The post Reimagine accessibility and foster inclusion in the modern workplace appeared first on Microsoft 365 Blog.

Go to Source

Share this

© 2010-2018 Alt-Tech Inc. All rights reserved.

Click Me