Web and Application Development Guide

Accessibility is a vital part of development of any product or materials, both on a human and a legal level. On a human and practical level, the applications developed within the college may be used by such a wide variety of audiences that the question isn't if anyone will need it, it's when and how. Given that the majority of disability is acquired in adulthood, a developer may even one day find themselves needing the accommodations they build today. From a legal standpoint, meeting accessibility standards is required by federal law and Ohio State University policies, both to protect the developers and the university from potential litigation. 

Requirements

Minimum Digital Accessibility Standards (MDAS) Developer Checklist

The Minimum Digital Accessibility Standards, or MDAS, Developer Checklist is a document designed to provide developers with an action item guide for meeting baseline accessibility compliance. While it is not completely exhaustive and may not cover all cases, it is meant to provide for the majority of development to help it meet the university-required WCAG 2.1 AA standard. 

In the MDAS you will find brief descriptions of specs, basic testing instructions, and a place to track each requirement and provide notes. You will also find links to tools, tutorials, and implementation information. 

The MDAS checklist document itself is designed to be filled out alongside development of the application and is required to be submitted as part of the final accessibility assessment. It is available from its University Code Repository site. 

MDAS on the OSU Accessibility website

MDAS Checklist on the University Code Repository (Login Required)

When is the best time to talk about accessibility? Right now.

As any developer or designer will tell you, the best time to set and act on a requirement is at the start of the process. The fact is that starting with a specification or requirement is much simpler and faster than having to rebuild later, and that remediation is much more expensive in both cost and time. 

Accessibility Assessment

The Accessibility Assessment is a process implemented by authorized digital accessibility staff members at the college. It is an evaluation of not just how accessible an application or web site is, but also helps to establish what accommodation resources may be needed. All software, applications, and web sites are required to undergo an accessibility assessment prior to being released or launched. Please note that an assessment can take quite some time, and an allowance should be made for any launch dates. The ETS website provides an overview of the assessment process at the link below.

An overview of the assessment process

Resources

WCAG 101: Understanding the Web Content Accessibility Guidelines

An article from the W3 Consortium that is a great primer for the concepts of WCAG and web accessibility.

ETS Website Digital Accessibility Section

ETS has built out simple guides to help with accessibility concepts and practices.

Ohio State University Digital Accessibility Center

Ohio State University's main website for accessibility resources, this site has more comprehensive information about Ohio State University's accessibility policies and practices.

Web Accessibility Initiative Website

This website contains a wealth of information about planning, development, and testing for accessibility. From fundamentals to tutorials and sample code, it is an invaluable resource for developers and designers.

Relevant Policies

• Accessibility Policy (PDF)
• Web Policy 

Identity and branding are part of what binds the university together, and provides a sense of unity that highlights the great work done at the university. Applying branding to software within a university context has multiple benefits. It ensures consistency and familiarity, cultivates trust and credibility, aligns the user experience with the institution's values, and contributes to differentiation and competitiveness. By leveraging branding in software, universities can effectively communicate their identity, enhance user experiences, and strengthen their overall brand perception within the academic community and beyond.

Requirements

All applications and websites are required to meet the basic branding guidelines of the university, and to provide for said branding in their design and elements. An individual application or web site may have its own feel and look, but that must comport with and respect the overall Ohio State University brand. Rather than specific requirements, guidelines are provided via the Brand Center (linked below), but some important concepts to touch on are:

• The name of the university and its information along with approved logos should be used.
• Logos and Ohio State University art may not be modified or changed, and should always be used tastefully and appropriately. 
• Official primary colors should only be used in approved shades.

Resources

The Ohio State University Brand Center

The Brand Center is a comprehensive guidebook for producing Ohio State University branded products. From digital to printed to physical items, it is the primary guide for all branding.

Buckeye UX (BUX)

Buckeye UX, or BUX, is a design system provided by Ohio State University's marketing and communications unit, and provides components to help a website be on brand quickly and with less effort. Use of BUX is not required for branding, but it is a great tool for designers and developers to start with and build out from.

Relevant Policies

• Web Policy 

Security is vital to every aspect of what we do at the university. Academic information, research data, and how that data is stored/used is important to keep in mind while designing and developing applications. 

Requirements

Information Security Control Requirements (ISCR)

The Information Security Control Requirements, or ISCR, is the main document that outlines requirements for application and web development at the university. In particular, the below sections should be focused on:

• IT7 Application Development-related Risk
• IT8 Development Process-related Risk
• IT13 Web Application-related Risk

In particular note that there may be applicable training requirements for some kinds of applications, or further assessments or requirements needed to use some resources. You can find the current version of the ISCR at the following link:

Information Security Control Requirements (ISCR)

Institutional Data vs Research Data

When you are working with information and data, one of the things to consider is what type of data you are dealing with: 

• Institutional Data is information from university systems about the university and its affiliated people. This can include contact information, grades, or personal data. It is governed by the Institutional Data Policy linked below.
• Research Data is information that is produced or handled by researchers at the university, and may have governance outside of just university policies and rules, including various laws and regulations. The Research Data Policy linked below should be used as guidance for this kind of information.

Resources

IDP Calculator

The IDP (Institutional Data Policy) calculator is a tool to help a designer or developer determine what data classification level their application is at when dealing with institutional data. 

Cloud Computing Guidelines

These guidelines are provided to help developers and designers navigate the requirements for using cloud resources including web hosting.

Cloud Assessment Registry

This registry is a great tool for helping to find an already evaluated third-party cloud application or service, and help you select one to meet the security requirements of your project.

Relevant Policies

• IT Security Policy 
• Institutional Data Policy (IDP)/li>
• Information Security Standard (ISS)
• Research Data Policy
• Web Policy