A practical addition to your policy program

As a policy administrator, few accomplishments are more meaningful than helping a colleague navigate a complex policy project. One of the most fulfilling aspects of my role as Policy & Records Analyst is providing guidance and support, especially when policy development and review feel unfamiliar or overwhelming.

At Concordia University of Edmonton (CUE), a small university in Edmonton, Alberta, known for its strong sense of community, that supportive spirit extends to our policy work. Our approach emphasizes collaboration, clarity, and long-term sustainability, ensuring that institutional policies remain aligned with the university’s vision, mission, and strategic objectives.

When I joined CUE, my aim was to establish a consistent, university-wide process for developing and reviewing policies. Early on, I recognized that building an effective policy program involves more than setting rules or monitoring compliance. It requires meaningful engagement with the people who contribute to the work. At CUE, policy development is a shared responsibility. Developers come from across the institution, bringing diverse expertise and varying levels of experience in policy writing. To support their success, I created the Policy Developers’ Toolkit—a user-focused resource designed to empower policy developers to engage confidently and effectively in the policy development and review process.

Why we created the toolkit

CUE’s five-step policy development and review process is designed to be straightforward, consistent across all policy instrument types, and easy to follow:

1.  A new policy action (creating a new policy or revising or rescinding an existing one) is proposed through a Policy Document Action Plan.
2. Upon endorsement, the policy owner assigns a policy developer or development team.
3. The development phase includes benchmarking, drafting, and consultation.
4. The policy is submitted to the Policy Review Committee for review.
5. Final approval is sought from the appropriate institutional authority.

Although the process itself is simple on paper, Step 3—development and revision by the policy developer—is often the most challenging. Policy developers are typically subject-matter experts, but they may not be familiar with translating their expertise into policy language that is clear, concise , and helpful.

As I worked alongside developers, I realized that providing one-on-one support for each project would not be sustainable long-term. I began by sharing checklists and other key reference documents, but it soon became clear that we needed a more comprehensive, centralized resource. The goal was twofold: to build confidence and understanding among our developers and to enable me, as the policy administrator, to manage multiple projects efficiently while still offering meaningful support.

Bringing these resources together in a central repository also allowed me to understand how they worked together and identify any gaps. This insight allowed me to refine the tools, build coherence, and ensure the approach remained practical and user-friendly.

What’s in the toolkit?

The Policy Developers’ Toolkit is hosted in CUE Connect, our employee intranet. It is organized around the key stages of the policy development and review cycle, and is designed to meet developers where they are—whether they are new to policy work or more experienced.

Current resources include:

• Policy Document Checklist – used by both policy developers and the Policy Review Committee to ensure policies are clear, concise, and helpful.
• Templates – standardized, fillable templates for various policy instruments.
  
• Standard Policy Definitions – to support clarity and consistency across all documents.
• Policy Benchmarking Tool – a custom Google search engine that scans 100+ Canadian post-secondary policy sites based on a keyword search.
• Instructional Videos – short walkthroughs, including a Quick Start Guide for new developers.
• Links to Key Resources – including our policy repository and essential documents like the Policy Document Action Plan.

Building Your Own Toolkit

If your institution does not yet have a policy development toolkit, or you are in the process of building one, here are a few steps I recommend:

1. Find a Home for Your Toolkit: Use a central, easily accessible location such as an employee intranet.
2. Start with What You Have: Gather existing resources like templates, checklists, and process guides.
3. Communicate Often: Link to the toolkit in training materials, auto-replies, and communications with policy developers.
4. Invite Feedback: Engage your users to learn what is working and what could be improved.
5. Review and Improve: A good toolkit should evolve with your policy program. Make updates a regular part of your work.
   

When we launched our toolkit, it coincided with significant revisions to our Policy on University Policy Documents. This timing allowed the toolkit to support implementation and promote a smoother transition. A well-timed, accessible toolkit can be a powerful aid in navigating institutional change.

Final Thoughts: Policy as a Community Effort

To me, policy work is one of the ways we express care for our institution and for one another. The Policy Developers’ Toolkit reflects that care by prioritizing clear guidance and accessible support to help our colleagues navigate what can sometimes feel like a complex process. While it is a practical tool, I also see it as a statement: policy work matters, and the people doing it deserve the right support to do it well.

Over time, consistent communication helped embed the toolkit into CUE’s institutional culture. It has become a staple in our policy trainings, a standard reference in policy-related email communications, and a key component of our broader efforts to promote policy literacy. Housed within our centralized hub for policy information, the toolkit makes it easy for employees to find the right resources at the right time.

As the toolkit becomes further integrated into our policy infrastructure, we continue to expand its scope. Planned additions include interactive training modules and workshops designed to build engagement and deepen institutional capacity in policy development. In this way, the toolkit is not a static product, but a growing and evolving support system that reflects our commitment to a thoughtful, community-centered approach.

As policy administrators, we know that policy work is both foundational and deeply human. While our documents provide structure, it is the people who shape them. The support they receive plays a vital role in ensuring policies reflect our institutional values and serve our communities well. By investing in the individuals who create and revise our policies, we help foster a culture of collaboration, inclusion, and shared purpose.
-
If you have tools or strategies that have proven helpful in your own policy toolkit, or if you are currently building one for your institution, I warmly invite you to share your insights and experiences. Please feel free to leave a comment or reach out to me at christine.valentine@concordia.ab.ca. I look forward to connecting and learning from your journey.

Making Your Policies Accessible to All Audiences

Most institutions are now aware of the need for recognizing and respecting the differences among the members of our stakeholder communities. As policy administrators, many of us are building equity review into our policy development processes.

Most of us now publish our institutions' policies online and share our policy drafts electronically, rather than in paper policy manuals or through paper documents. Just as it's important to consider adding equity review to the development of policies, it's also important that we consider how to prepare the content for distribution in ways that make it accessible to a wide range of people, including those who use assistive devices.

Here are some considerations for your institutions, all of which we’ve put in place here at Washington State University (WSU):

• Establish a policy and/or procedures for improving the accessibility of online and electronic content. As an example, here at WSU we have an executive policy and supporting procedures:
  • University Web Accessibility Policy
  • Ensuring Electronic and Information Technology Accessibility
• Require web accessibility training for all institutional online developers and webmasters.
• Provide issue reporting and complaint/grievance procedures regarding accessibility issues.

At WSU, our Web Communications unit handles web accessibility problems and our institution's ADA (Americans with Disabilities Act) coordinator is responsible for managing access complaints and grievances.

Creating Accessible Word and PDF Documents

Most of us use Word to create our source documents and either Word or PDF for drafts and creating web versions of our policies. Taking in consideration of assistive devices, here's some key components for making Word and PDF documents accessible to all:

• Headings:
  • Headings create a hierarchy in the document that a screen reader can follow.
• Document Title, Description, and Tags:
  • A default document title is necessary for a screen reader to be able to scan and read out loud to its user.
  • A document description gives screen reader users a brief summary of the document they are about to read.
  • Document tags allow a screen reader to know if they are looking at an image, a paragraph, a heading, etc.
• Hyperlinks:
  • Hyperlinks need to have clearly defined labels of the destination of each link so that a screen reader is able to read them out loud when scanning the document.
  • It's preferable to embed link URLs (attach the URL in the background to a word or phrase using the Link function), also known as contextual links, rather than writing out URLs in the document.
• Tables:
  • Clear table structures and headers are necessary for a screen reader to be able to scan the document.
• Alt Text:
  • Alt Text data allows a screen reader to scan a description of tables, figures, or images that may be on the document.
• Lists:
  • The built in formatting tools of Word make it easier for the screen reader to scan the document.
• Capitalized Words:
  • Use bold for emphasis and avoiding capitalization of words.
  • Assistive devices may provide capitalized words to users by reading each individual letter, instead of complete words.
• Tab/Reading Order
  • For PDFs, identifying the reading order of a document’s text helps a screen reader present the text as it is meant to be read, rather than just as random blocks of text.
    

Creating Fully Functional PDFs from Word

With the latest versions of Word in Office365, all accessibility functionality in a Word source document may be directly transferred to a PDF version:

• Select File->Save As
• Change the file type (suffix) from the default Word Document (.docx) to PDF (.pdf).
  A PDF file created in this way includes all of your active hyperlinks and other functionality.
  

Creating Accessible Documents from Scanned Images

In order to make scanned document images accessible to a screen reader user, a few things need to be done, otherwise none of the information on the document can be read by a screen reader:

• Make or convert the scanned image to PDF
• Under Tools (in Adobe Acrobat Pro):
  • Select Optical Character Recognition (OCR)
  • Select Text Recognition and In This File, and
  • Select the pages to be included
• Under Tools:
  • Select Action Wizard, then
  • Select Make Accessible
  • Select Find Recognize Text Using OCR
• In the Recognize Text -- General Settings window:
  • Select the applicable language and
  • Select Searchable as the PDF Output Style
• Select OK
  

Accessibility Guides

The process of increasing equity in our policies and policy access is ongoing. Here are some accessibility guides to provide you with further ideas as you get started:

• World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG) 2.0
• U.S. General Services Administration (GSA) 18F Accessibility Guide
• WSU Web Communications Accessibility Guides

Framework Recommendations Instead of Templates

In conversations and webinars with other policy administrators, the debate about whether or not to use templates for writing and developing policies continually comes up. A number of institutions mandate the use of one or more templates for their users who want to develop policy and/or procedures documents.

I've worked for the past 25 years in the administrative policies office for Washington State University. We've chosen not to use a template for developing the administrative policies and/or procedures our office publishes. We do have a style guide, but it’s mostly involved with formatting and layout so that sections and policies have a uniform “look.” Our choice has predominantly been based on the idea of providing flexibility to our subject expert departments as they update or add new sections to our long-established administrative policy manuals.

In accordance with WSU's executive Policy on Policies (EP5), departments may begin development of their administrative policy/procedure rough drafts prior to bringing my office into the process or may request our assistance with developing the drafts from the beginning. As subject expert administrators get started, we do occasionally get requests for policy framework guidance from those who are new to policy writing and development.

Here’s a general outline that my office recommends for writing a new policy or policy/procedure section for placement in one of our administrative manuals:

• Overview and/or Policy Statement
  
  It’s sometimes useful to have both. If a section is especially long, placing a set of links to subsections in the document in the overview can be useful. For examples, see the beginnings of WSU's policy sections EP8 and EP38.
  
  In a section that's predominantly procedural, an overview might be more appropriate as a place to provide a summary of or references to the applicable policy.
  
  
• Purpose
  
  A purpose statement provides a brief description of the purpose of the policy and/or activity. In some cases, a purpose statement is provided in an overview or policy statement.
  
  
• Scope
  
  A scope statement describes the limitations or boundaries of the policy/procedure. Some writers choose to combine scope statements/subsections in either an overview or policy statement or within an applicability statement.
  
  
• Applicability
  
  An applicability statement or subsection describes the members of the institution's community (internal and/or external) directly impacted by the policy and/or expected to follow the policy/procedures.
  
  
• Roles and Responsibilities
  
  Roles and responsibilities statements provide a summary of the actions and/expectations each employee or role category is expected to fulfill with relation to the policy/procedures.
  
  
• Requirements
  
  Policy requirements are provided in this subsection. If procedures are included, any required procedural steps would be provided in the order the actions are to occur.
  
  
• Procedures (if applicable)
  
  Some institutions choose to keep policies and procedures separate. At WSU, we have quite a number of combined policy and procedures sections in our administrative manuals. For the most part, we recommend publishing procedures and policy/procedures within our business and safety manuals. However, we do have a small number of executive policies in which the executive administrators insisted upon including both policies and procedures.
  
  
• Definitions
  
  We recommend providing definitions applicable to the policy/procedures in their own subsection, especially if terms are used that are specific to a subject and/or include jargon. If there are only one or two terms that need to be defined, the definitions may be included directly with the reference.
  
  If this subsection is short, it might be placed after the applicability statement. However, if the definitions list is longer than a page, we often recommend placing the subsection at or near the end and providing an internal document link and/or reference, if needed, earlier in the policy.
  
  
• Additional Resources
  An additional resources subsection provides descriptions or lists and references (e.g., website URLs) including, but not limited to, supporting department contacts, state and federal agencies' websites, other supporting or related institutional policies and procedures.

Every policy office and institution handles their policy development process differently, and there's really no right or wrong answer. Does your institution mandate policy/procedure templates? Or make framework recommendations? Things to consider for both you and your users…

NOTE: ACUPA members have access to a number of resources, including templates, samples, and other tools that you may find useful in writing and developing your policies and procedures. To access the Templates and Tools under the Resources tab, sign in as a member.