What email address or phone number would you like to use to sign in to Docs.com?
If you already have an account that you use with Office or other Microsoft services, enter it here.
Or sign in with:
Signing in allows you to download and like content, and it provides the authors analytical data about your interactions with their content.
Embed code for: Office Accessibility Writing
Select a size
Office Accessibility Writing Instructions
This project runs through June. It involves writing or updating 300+ application (Word, PowerPoint, etc.) accessibility topics. Microsoft has new standards for accessibility and the topics are being written/updated to meet those standards. It’s important that you know that these topics are all being written for people who cannot see—so absolutely no usage of the mouse, no references to clicking in any of your work, no references to icons, etc. We’ll be providing guidelines to help you understand how to write accessible instructions.
Because screen readers are the primary way users will read this content, the topic template must have standard styles; we will provide you with a sample topic that has standard styles. There should be no customizing of styles or deviating from the topic template.
Topics are for the information worker, administrator, and IT Pro audiences. They cover the core Office products (online version and desktop version, mainly 2016) and a variety of other products like Skype and SharePoint. They also cover products operating on a variety of platforms, including Windows, iOS devices, and Android devices. We will be writing IW topics first.
Because the project documents accessibility, writers and testers will need to use Narrator, the screen reader built into Windows, and the most popular general screen reader, JAWS.
In some cases, we have existing content to start with either to revise or as a guide to help writers in their research. We also have related content links and the client indicates that there is existing documentation that can be found via the web to use as a guide. That means you will likely need to do some searching and digging.
Later in the project, we may be documenting during product development. Some Microsoft teams are using an agile approach, which means no specifications. Instead, writers would have versions of the product and access to the minimal content the team is using for development, such as sketches, PowerPoint decks, and notes. That means that writers will need to do their own exploration and testing and use email/meetings to communicate directly with PMs to get more information, when needed.
FYI: Once writing assignments are complete, the client, Becky Montgomery, will introduce each writer to the relevant PMs via email.
The Microsoft Style Guide has been updated in the past year. If you haven’t worked on a recent writing project at Microsoft, you may need to familiarize yourself with the latest guidelines. The latest version can be found at
https://worldready.cloudapp.net/StyleGuide/Read?id=1413https://worldready.cloudapp.net/StyleGuide/Read?id=1413. Find accessible content information at
NOTE: Client reviews will actually be more like usability tests of the content. The client has a team of visually impaired people (real users!) who will use our topics with the products and provide the writers with feedback.
Lastly, in addition to the topics we’re writing, each writer will complete four audio scripts developed based on existing, written topics. Neicole will be doing one in January to understand the deliverable and process better, and then provide templates and instructions. Writers will start on audio scripts in February and are expected to deliver one a month from February through June.
Dail Bridges (
mailto:email@example.com@ronline.com) – Account Manager PM, Content Manager, Editor
mailto:(firstname.lastname@example.org(email@example.com) – Billing PM
mailto:(firstname.lastname@example.org(email@example.com) – Lead Writer, NMC
mailto:(firstname.lastname@example.org(email@example.com) – Writer, NR
mailto:(firstname.lastname@example.org(email@example.com) – Writer, JL
mailto:(firstname.lastname@example.org(email@example.com) – Writer, TS
mailto:(firstname.lastname@example.org(email@example.com) – Writer, MP
Katherine Inman (Katherine Inman (
mailto:firstname.lastname@example.org@ronline.com) – Writer, KI
mailto:(LesliS@ronline.com(LesliS@ronline.com) – Writer, LS
mailto:(email@example.com(firstname.lastname@example.org) – Editor
mailto:(email@example.com(firstname.lastname@example.org) – Editor
mailto:(email@example.com(firstname.lastname@example.org) – Topic Tester
mailto:(LesliS@ronline.com(LesliS@ronline.com) – Topic Tester
mailto:(email@example.com(firstname.lastname@example.org) – Topic Tester
mailto:(email@example.com(firstname.lastname@example.org) – Topic Tester
Martin McCann (
mailto:email@example.com@artdart.com) – Graphic Artist
We’ll use RO email to communicate with one another (not everyone is/has a v- account). There may also be communications through Microsoft. The RO Distribution group:
mailto:firstname.lastname@example.org@ronline.com. See above for individual email addresses.
We will also have a weekly team meeting, to be scheduled by Dail. It may move to bi-weekly later.
To track topics and status, we’ll be using a combination of naming conventions for the files, a folder structure that mimics the process steps, and email notifications at various handoffs.
We’ll be using Dropbox as our main internal repository for documents and project information. We have a SharePoint site from the client, but the general team will not access it. Dail will coordinate all official handoffs to and from the client, including returned reviews. (However, writers are still expected to reach out directly to reviewers and have conversations, as needed.)
Dail is creating a master spreadsheet for tracking topics. It includes a column for the core filename to use, which is based on the name of the topic. For example, if the topic is Insert a picture using a screen reader in Word Online, the core filename might be Word_InsertPicture. Use this core filename as your starting point and then follow this convention for all files in Dropbox:
The platform and its abbreviation is listed in Dail’s spreadsheet. For references, the platforms that may be noted are:
15RO2052 Office Accessibility/ PM
Email notification when assignments are ready.
15RO2052 Office Accessibility/
You can work locally and use this folder for backups.
Art request, if needed (writer works w/artist)
CC: Dail and Neicole on art requests so we can track them
See spreadsheet for QA assignment;
Writer Email the tester and CC Dail when your topic is ready for testing
Writer Move your topic to this folder when it’s ready for keystroke testing;
Tester and writer work directly on any questions/issues
Incorp keystroke changes
If you’re working within Dropbox, you can incorp your changes in this working folder
(may be batched)
Move your topic to this folder when it’s ready for client review;
Email Dail when your topic is ready for client review;
Topics are expected to be technically accurate as much as possible, but client knows they have not been edited
If your topic will include art, the draft art should be included for review
Use comments in the file for any specific review notes or reviewer comments you have
We may be batching topics for review, so plan to work on other topics while these are out for review
Dail will place your reviewed files here;
Dail will notify you by email when your topics are back from review;
If you’re working in Dropbox, you can use this as your working location for incorp
Writer, if you included art, it’s your job to coordinate with the artist on any review changes
2nd keystroke (optional)
See above; same process, with a different folder
Notify Dail if you need a second keystroke on the topic and she will assign a tester
Incorp 2nd keystroke changes (optional)
Move your topic here when it’s ready for edit;
See spreadsheet for editing assignment;
Email your editor and CC Dail when the topic is ready for editing;
Include final art in the edit handoff
Incorp edit changes
Editors, place edited topics in this folder;
Email the writer and CC Dail when editing is complete
If you’re working in Dropbox, you can work on the file in this folder
Writer, it’s your job to coordinate with the artist on any edit changes
Handoff to client
Move your topic to this folder when it is ready for final handoff;
Email Dail and CC Neicole when your topic is ready for handoff
Writers and testers will need to:
Install Office16. Instructions to come. Doug Yoder will provide IT support, if necessary.
Install JAWS which we’re in the process of obtaining.
Use Windows 8, 8.1 or Windows 10.
Install Dropbox and join the folder using the email invitation you should have received.
We’ll provide a template to use and guidelines to follow specifically for this project. A few things to note, now:
You should document to JAWS, which has 70% market share in screen readers, and note exceptions when Narrator (or other OS screen readers in the case of iOS or Android) handles things differently. Our template will call out how to do this.
Screen readers rely on the default styles in Word, so don’t use custom styles under any circumstances. You’ll need to use the specific styles in the template.
As you document, it’s important to try steps “blind,” i.e. by using the screen reader to follow your steps and not looking at the screen as much as possible. This will help you find places where the instructions won’t make sense to someone who can’t see.
Refer to the following documents to aid in your writing:
https://www.dropbox.com/s/rv2hf9e743qr8y8/Keyboard%20Commands%20for%20Narrator%20and%20Office.xlsx?dl=0Keyboard commands for Narrator and Office.xlsx
https://www.dropbox.com/s/1tr55mogyfkppwl/Office%20Accessibility%20Template%20and%20Guidelines_V3.docx?dl=0Office Accessibility Template and Guidelines_V3.docx – The template and writing guidelines to use.
https://www.dropbox.com/s/xx6gvoj0qbr8u4d/Key%20names1.docx?dl=0Key names1.docx — Microsoft’s guidelines for key names.
https://support.office.com/en-us/article/Keyboard-shortcuts-for-Microsoft-Word-2016-for-Windows-95ef89dd-7142-4b50-afb2-f762f663ceb2Keyboard Shortcuts for Word 2016
https://support.office.com/en-IE/article/Keyboard-shortcuts-in-Excel-2016-for-Windows-e56d0e8f-a566-4094-8604-5190ae802612Keyboard Shortcuts for Excel 2016
http://www.indezine.com/products/powerpoint/learn/customize/powerpoint-shortcuts-2016.htmlKeyboard Shortcuts for PowerPoint 2016 (not by Microsoft, but all I could find)
Find your topics to test in your respective folders in the 2_Keystroke folder on Dropbox:
Your job is to test the draft instructions to make sure you can follow them to complete the task in the product, on the particular platform of the topic. This means using both JAWS and the OS screen reader (Narrator for Windows, VoiceOver for Apple, etc.) to test. Just as for the writers, you should test “blind” and try not to read the topic or look at the screen, but instead rely on the screen reader. You cannot use a mouse or a touchpad as you test. You’re checking:
The topics at the Beginner verbosity level in JAWS. (Writers are using Intermediate. Please test in Beginner.)
Beginner is probably the default, but please check. You can change this setting here:
Utilities > Settings Center
How the screen reader speaks the topic. If there are style issues, for instance, you’ll probably find the topic doesn’t make sense when it’s spoken through the reader. We suggest that you go sentence by sentence or line by line with the screen reader (JAWS: Alt+ Down Arrow; Narrator: CapsLock + O) and test each instruction in each sentence.
Whether you can complete the steps exactly as written. Follow them exactly. Remember, you cannot click anything, since this is a mouse action. Watch for usage of "click."
Whether the results are correct. If you follow the steps, does the procedure work?
We’ll have to see what the best way to test is, but to start, we’ll suggest you disconnect your mouse and don’t use any touchpad, open the app and the topic with the reader, and then follow the instructions without looking at the screen. Note any steps you can’t complete because of the way the topic is written and why. If you do complete the procedure, see if the results are what they are supposed to be. If not, walk through the steps again, this time looking at the screen, to see where the steps are incorrect and note it.
Use change tracking in the topic to note issues. Do feel free to capture screen shots and include them in your QA copy to aid the writer.
Work directly with your Writer on their topic—move completed topics to 3_KeystrokeComplete and email them when topics are there; feel free to move them one at a time as you are done, and alert the writer via email (please cc me on all communications with the writers)
Writers are responsible for incorporating your feedback and moving topics into the
Editors will perform a copy edit/proof as one of the last tasks before handoff. You won’t be expected to test the topic. (But, given resources, we may ask you to help as a Tester—see above-- if you have time/bandwidth.) Please check for style and consistency, make sure the topic is written according to the accessibility guidelines within MSTP (and any other guidelines provided here), and verify that all the styles are the standard ones and none have been changed or customized.
Editors, if writers have flagged places where they’d like to link to another topic, please determine if the topic already exists in our deliverables and provide the link. If it doesn’t exist, please update the comment to say so and we’ll let the client make a decision.
Refer to the following documents to aid in your editing:
https://www.dropbox.com/s/xx6gvoj0qbr8u4d/Key%20names1.docx?dl=0Key names1.docx — Microsoft’s guidelines for key names.“blind” and try not to read the topic or look at the screen, but instead rely on the screen reader. You cannot use a mouse or a touchpad as you test. You’re checking:
The topics at the Beginner verbosity level in JAWS. (Writers