Accessible Forms Guidelines

Every NCU form must work for people who use screen readers, keyboards, screen magnifiers, voice control, or other assistive tools. Follow these guidelines any time you build or change a form.

Every NCU form must work for people who use screen readers, keyboards, screen magnifiers, voice control, or other assistive tools. Follow these guidelines any time you build or change a form. They follow WCAG 2.1 Level AA, the standard NCU uses for digital forms.

Which Forms These Cover

• Forms you build: Use only the approved tools listed in Creating Forms: Microsoft Forms, TeamDynamix, and FormAssembly (including FormAssembly connected to Salesforce).
• Forms in a platform or product: Forms that come with a vendor system, such as admissions, payments, HR, or the learning management system. You may not control how these look, but NCU still owes people equal access. Contact OIT before buying or renewing any product that collects information.
• After Submit: Confirmation pages and emails, login and “save and resume” screens, and any file the form creates.

Labels and Layout

• Visible labels: Every field needs a label that stays on screen. Placeholder text (gray text inside the box) cannot serve as the label, because it disappears when people start typing.
• One question per field: Avoid grids. In Microsoft Forms, skip the Likert question type and ask each item as its own Choice question. In FormAssembly, avoid matrix fields.
• Group related choices: Put radio buttons and checkboxes under a clear question, so a screen reader reads the question along with each choice.
• Required fields: Mark them in words (“Required”) or explain the asterisk at the top of the form. Never use color alone.
• Color and contrast: Use the tool’s default theme or dark text on a light background. Do not place text over images.
• Zoom: Check the form at 200% and 400% browser zoom. Text should wrap, with nothing cut off or overlapping.
• Time limits: Avoid them. If a form must time out, warn people first and let them ask for more time.

Keyboard Use

• Keyboard only: Someone must be able to fill out and submit the whole form with only Tab, Shift+Tab, arrow keys, Spacebar, and Enter.
• Visible focus: A clear outline shows which field or button you are on at every step.
• Logical order: Tab moves through fields in the same order people read them.
• No traps: Date pickers, pop-ups, and drop-down lists must let people Tab or Escape back out.
• No surprises: Picking an answer never submits the form or jumps to a new page.
• CAPTCHA: Any “prove you are human” check must offer an option that does not depend on sight.

Instructions and Errors

• Instructions first: Put format rules (dates, phone numbers, file types) in the label or right under it, before people type.
• Errors in words: Error messages name the field and say how to fix it. Red color alone does not count.
• Keep answers: After an error, people should not have to re-enter answers they got right.
• Review step: For applications, payments, contracts, and financial aid, let people review their answers before final submission.
• Plain language: Short questions, common words, and no unexplained acronyms.

After Submit

• Confirmations: Use real text, not images of text. Links say where they go (“Download your receipt,” not “Click here”).
• Files the form creates: PDFs and receipts must be tagged so screen readers can read them. Scanned or flat PDFs do not work.
• No PDF-only forms: Do not post a fillable PDF or Word file as the only way to complete a process. Build it in an approved form tool instead.

Add a Help Line to Every Form

Every form needs a short help line near the top. You can copy this one:

Who needs help	Contact	How to reach them
Students and applicants	Office of Student Development	studlife@northcentral.edu
Employees and job applicants	Office of Human Resources	612.343.4412 · hr@northcentral.edu

When someone reports a problem, help them right away, keep their deadline, and let OIT know which form failed.

When a Tool Cannot Meet a Guideline

Some tools and vendor platforms cannot meet every item above. That happens, and it does not always mean you cannot use the form. It does mean you must:

1. Keep the help line on the form.
2. Offer another way to complete it right away, with the same deadline.
3. Submit an OIT ticket naming the form and the item it fails, so OIT can track it and raise it with the vendor.

Never leave someone without a way to finish.

Quick Check Before Publishing

Run this ten-minute check before you publish a new or changed form.

• ☐ Fill out and submit the whole form with only the keyboard.
• ☐ Look for a visible focus outline on every field and button.
• ☐ Check that every field has a label that stays on screen.
• ☐ Confirm the form has no grid, Likert, or matrix questions.
• ☐ Leave a required field blank, submit, and confirm the error names the field in words.
• ☐ Zoom to 200%, then 400%, and confirm nothing overlaps or needs side-to-side scrolling.
• ☐ Open any file the form creates and confirm you can select the text.
• ☐ Confirm the help line appears.
• ☐ Run a free checker such as WAVE and fix what it flags.

Questions about building an accessible form? Submit an OIT ticket.