Accessibility Statement

In short

• We build Tillyard to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. That is the standard we aim for. We do not claim that every page meets it.
• The site is almost all text. There is no audio or video here to caption. A member can add a picture only as a figure in a paper, and each figure carries a caption and a description that its author writes.
• Every main task is meant to work with a keyboard alone, with a screen reader, on a narrow screen and as ordinary forms. Live rooms have a list form and a control that pauses updates.
• We check with automated tests, with scripted keyboard journeys and with checks of our own. A hand pass with a screen reader is still to come. Section 5 lists what was done and when. No outside specialist has reviewed the site yet.
• Section 6 lists what we know does not work well yet, each with a way round it.
• We do not use an accessibility overlay widget and have no plan to.
• If you meet a barrier, write to accessibility@tillyard.org. You do not need an account. If the barrier stops you doing something, we can usually help you get it done another way (section 9).
• This statement describes what we aim for and what we do. It is not a promise that nobody ever meets a barrier here.

If this summary and the full text below ever differ, the full text governs.

1 What this statement covers

1.1 What this statement covers, and who is speaking

Tillyard is an Ohio nonprofit corporation. "We" and "us" mean Tillyard.

This statement covers:

• the website at tillyard.org, signed in and signed out: The Shop, Tillyard Research, Pursuits, The Record, The Workbench, Notes, The Almanac, account settings, the policy pages, and the forms for reports, removal requests and disputes;
• public pages that people outside Tillyard open, such as a published paper, or a record page that someone follows from a résumé;
• the email we send;
• things the site makes for you to take away: a printed record, a résumé exported from The Workbench, a calendar file, a QR code, and the printable menu and table tents;
• the staff console, which members never see but which staff with a disability may need to use.

1.2 What it does not cover

• Other websites we link to or send you to: Stripe's payment pages, LinkedIn, a video-call service that a table's opener links to, an opportunity listing, a publisher's page behind a DOI. Section 10 says more.
• What members write. We give members structure to write with, and the editor reads every paper before it is published, but we do not rewrite members' work to make it easier to read.
• Your own browser, device and assistive technology. We test with the ones in section 5 and cannot test with all of them.

1.3 How this fits with other documents

• The Terms of Use are the agreement between you and us. They say that this statement describes our aims and is not a warranty.
• The Privacy Notice says what happens to anything you send us, including a message about a barrier.
• The Cookie and Storage Statement describes the small cookie that remembers your reading settings.

On accessibility, this statement is the more specific document, and where it and another document cover the same point this one governs. Section 37.5 of the Terms of Use sets the order among all our documents, including the sections of those terms that prevail over every other document. Nothing here changes any right the law gives you (section 12).

1.4 Words used here

Words that have one meaning in every one of our documents, such as member, visitor, staff, the editor, record item, hold, case and tip, are defined in Definitions. The words below are added for this document's own subject, or repeated from Definitions for convenience. If a repeated meaning ever differs, Definitions governs the meaning of the word.

• WCAG is the Web Content Accessibility Guidelines, a public standard written by the World Wide Web Consortium (W3C). It is a list of testable requirements called success criteria.
• Level AA is the middle of WCAG's three levels. Meeting it means meeting every Level A and every Level AA criterion.
• Assistive technology is software or hardware a person uses to operate a computer: a screen reader, a screen magnifier, voice control, a switch, a braille display.
• A barrier is anything about the site that stops or slows a person with a disability from doing what other people can do here.
• A live update is a change to a page that happens without you asking for it, such as a new line of table chat.
• An overlay is a third-party script that sits on top of a website and claims to make it accessible by itself (section 7).
• Reflow means the page rearranges into one column when it is narrow or magnified, so you do not have to scroll sideways to read a line.

2 What we aim for

2.1 The standard

We aim to meet WCAG 2.2 at Level AA on every page and in every task, in both the light and the dark theme, signed in and signed out.

We chose version 2.2 because it is the current version and because several things it added matter for a site like this one: a minimum size for anything you tap or click, an alternative to every dragging movement, help that sits in the same place on every page, not being asked to type the same thing twice, a keyboard focus that is never hidden behind another part of the page, and sign-in that does not depend on remembering or solving something.

2.2 What this means

Meeting the standard means, among other things, that:

• everything can be reached and operated from a keyboard, with a focus marker you can always see;
• every control and field has a name a screen reader can speak;
• text has enough contrast against its background, and nothing is said by colour alone;
• the page still works when text is enlarged, when the window is narrow and at 400% zoom;
• nothing moves, flashes or makes a sound without a way to stop it;
• mistakes in a form are named in words, next to the field, with a suggestion where we can give one;
• changes that happen by themselves are announced to assistive technology, and can be paused.

2.3 What we do not claim

• We do not claim that the site meets the standard everywhere. It is built and checked by a very small team, checks miss things, and new work can introduce a barrier. Section 6 lists the gaps we know about.
• No outside body has examined the site and declared that it meets the standard, and we show no badge or seal saying so.
• No rule we know of sets a technical accessibility standard for a private website like this one. WCAG 2.2 at Level AA is the standard we chose to hold ourselves to.

3 How the site is built

Each point in this section describes how the site is meant to work. If you find a page where it does not, that is a barrier we want to hear about.

3.1 Text first

• Tillyard is almost all text. There is no hosted audio or video, so there is nothing to caption or transcribe. A figure in a paper carries a description its author writes, and the author may write it well or badly.
• Members can upload only figures in papers and receipts for research grants. A member is shown by their initials, not by a photograph.
• Where a page has a picture of something, such as the floor plan of a room in The Shop, the same thing is also there as a list you can read and operate. The list is the real interface. The picture is a drawing of it.
• A QR code always comes with the same address written out as text, and a short code you can type.
• Links that members write appear as text, not as previews or embedded content.

3.2 Structure and finding your way

• Every page has one main heading, headings in order beneath it, and labelled regions for the banner, navigation, main content and footer.
• A "skip to content" link is the first thing a keyboard reaches.
• Every page has a title that names the thing, the area and Tillyard, in that order, so tabs and history lists read sensibly.
• Navigation is in the same place and the same order on every page. So is the way to get help and the way to report something.
• Tables have captions and header cells. Lists are real lists.

3.3 Keyboard

• Every control can be reached and used from the keyboard.
• The focus marker is always visible, including in the dark theme and when your system forces its own colours.
• Nothing needs dragging. Anything that can be reordered has buttons to move it.
• Single-key shortcuts are off unless you switch them on, so they cannot collide with a screen reader or voice control.
• Dialogs take focus when they open, keep it while they are open, and hand it back when they close.

3.4 Seeing the page

• Body text is set at a contrast of at least 4.5 to 1 against its background, and the edges of controls at least 3 to 1.
• Nothing is said by colour alone. A status is always a word, such as "Off", "Waiting" or "Withdrawn", and never only a coloured dot.
• There is a light theme and a dark theme, both designed. The site follows your device unless you choose one.
• When your system forces its own colours, as Windows high-contrast modes do, the site keeps its outlines and marks.
• Pages reflow into one column at a width of 320 CSS pixels and at 400% zoom.
• You can set the site's text to Standard, Large or Larger, on top of whatever your browser does.
• Fonts are served from our own address, so text appears without calling another company.

3.5 Movement and sound

• Movement is brief. If your device asks for reduced motion, movement is removed. You can also choose "Reduce" on the site whatever your device says.
• Nothing flashes.
• Sounds are off unless you switch them on.

3.6 Pointing and tapping

• Anything you tap or click is at least 24 by 24 CSS pixels.
• Nothing needs a path traced with a finger, a pinch or two fingers at once.

3.7 Forms and mistakes

• Every field has a visible label. Hints sit under the field and are tied to it for screen readers.
• When a form comes back with mistakes, a summary at the top takes focus, names each problem in words and links to the field.
• Every main task works as a ordinary form that a browser can submit without scripts. Scripts add convenience on top.
• After you submit a form, the confirmation is shown as text and announced.
• We aim not to ask you to type something again that you already gave us in the same task.

3.8 Things that change by themselves

• Pages that update live, such as a room in The Shop or a conversation in Notes, announce changes through one polite status region and one log region, so that a screen reader is told once and in order.
• Every such page has a "pause live updates" control. While it is on, nothing is announced and the page does not change under you. When you resume, you get what you missed.
• You can set live pages to start paused, every time, under "Reading and motion".

3.9 Time

• Reading another member's work has no timer.
• A sign-in code works for only a few minutes. That is a security measure. If it runs out, ask for another.
• Chat at a table is open throughout a session, so it cannot be slowed for one person (section 6.4). Focusing stops it reaching you.
• You stay signed in for a long time, so that you are not signed out in the middle of something. Drafts are saved as you write.

3.10 Signing in and proving you are a person

• You can sign in with a passkey, which asks for whatever your own device uses, such as a fingerprint, a face, a PIN or a security key. A password is optional, and a one-time code emailed to you works too. There is no puzzle to solve.
• When we email a code, you can paste it. The code field is marked so that browsers and password managers can fill it in.
• Forms open to people who are not signed in sit behind a bot check run by Cloudflare, called Turnstile. It usually needs nothing from you, or one tick. We set no picture or sound puzzles of our own. Section 6.3 says what to do if it will not let you through.

3.11 Words

• We aim to write in short sentences, in sentence case.
• Every policy opens with a summary called "In short".
• The Shop uses coffee-house words for some things. We aim to give the ordinary meaning wherever a house word is used on a control.
• The site is in English, and pages are marked as English for screen readers.

3.12 Email

• Every email we send has a text-only version alongside the designed one.
• No email relies on an image, and none loads an image from elsewhere.
• Each email is about one thing and has at most one button, whose label says where it goes.

The Email and Communications Policy says more.

3.13 Print and files

• Pages meant for printing, such as a record of activity or a policy, have a print layout.
• Every policy is also available as a text-only file.
• The résumé template in The Workbench is a single column, which reads in order for both screen readers and the software employers use to read résumés.

3.14 Reading settings

You can change these under Account, "Reading and motion". They are kept in a small cookie on your device, so they also apply before you sign in on that device. The cookie holds settings and no identifier.

4 Area by area

4.1 The Shop

A room is a list of tables, and a table is a list of the people at it and what each said they were working on. You can join, order, take a seat, switch Focusing on or off and leave from that list with a keyboard. Table chat is a log: new lines are added at the end and announced once. The floor plan drawing shows the same information and is not needed to use the room. If the drawing fails to load, the room still works.

4.2 Notes

A conversation is a list of messages under day headings. A new note is announced once. Nothing is announced while the page is paused. After you send, take back or load earlier notes, focus goes somewhere sensible and is not thrown to the top of the page.

4.3 Tillyard Research

Reading and scoring a paper is a form with no timer. The steps of submitting a paper are shown as a numbered list with the current step marked for assistive technology.

4.4 The Record

A record page says its status in words. The page a stranger opens from a résumé is a short document with labelled rows: who, what, when and how we know. The link, the code and the QR code all lead to the same page.

4.5 The Workbench

The résumé tools run in your browser. Sections and bullets are reordered with buttons. Importing a résumé reads the file on your own device, in steps you can move through with a keyboard. Any chart or visual summary has the same information as a list.

4.6 Forms anyone can use

The forms for reporting something, asking for a removal, and disputing or correcting something need no account. Each one works with a keyboard and a screen reader, and each has an email or postal route as well (section 9).

5 How we check

5.1 Automated checks

Automated accessibility checks, using the open-source axe-core engine at WCAG 2.2 levels A and AA with its best-practice rules, are run in Chrome against the pages of every part of the site, in both themes and at 320 CSS pixels wide. We run them before a part of the site is called finished and again before launch. A part of the site is not treated as finished while those checks report a problem on it. We also run checks of our own for what axe cannot see: that the words on a control are part of its name, that targets are at least 24 pixels or spaced apart, that the edge of a control has enough contrast, that text still fits when its spacing is widened, that nothing moves when the system asks for less motion, and that live regions stay quiet.

Automated checks find only some kinds of barrier. They can tell that a button has no name. They cannot tell whether the name makes sense, or whether a page is confusing to move through. That is why a person has to go through the site as well, and why sections 5.3 and 5.5 say what has not been done.

5.2 Keyboard journeys and page walks

• Scripts, driving Chrome, walk the main journeys with the keyboard alone: joining as far as the code step, the study rooms (the list, sitting down, the map, a person's card and the 3D menu), Messages (opening a conversation, jumping to the box, sending), the research editor (typing, shortcuts, a dialog, a long paper) and the résumé builder (starting, adding an entry, moving it).
• A script also presses Tab through about 80 pages as a visitor, a member and the owner. It checks that the mark showing where you are can be seen, that no bar hides it and that nothing traps it.
• Pages are checked at 320 CSS pixels wide and at 200% zoom, with text spacing widened, and with reduced motion on.
• Passkey sign-in and voice calls could not be driven by a script and have not been walked.

5.3 With a screen reader

No person has used a screen reader on the site yet. The scripts above check what a screen reader would be given: names for controls, headings, landmarks, error messages that are announced, and the two live regions the site uses (one polite status line and one log). A hand pass with a screen reader on the main journeys is still to come, and until it is done we do not say that the site works with one.

5.4 Email and print

Every email carries a text-only version. The email templates and the print layouts have not yet been checked by a person in mail programs or from a print preview. That check is still to come.

5.5 What we have not done

• No outside accessibility specialist has reviewed the site.
• We have not yet run sessions with disabled people using the site. Until we do, what we hear from you is the best information we have.
• We have not produced a formal conformance report of the kind sometimes called a VPAT.
• We have used Chrome only. Safari and Firefox have not been tried, and other browsers and assistive technologies may behave differently.
• No screen reader has been used on the site, and no mail program has been used to check the emails (sections 5.3 and 5.4).

5.6 The latest review

Date of the last review of this statement and the site against it: 20 October 2026.

6 What we know does not work well yet

Each item has a way round it. We give no dates for fixes, because a date we missed would be worse than none.

6.1 Nobody outside has checked our work

The site is checked by the people who built it. That is a real limit: we are likely to have missed things that a specialist, or a person who uses assistive technology every day, would find quickly.

Way round: tell us (section 8). A report from you is acted on ahead of our own guesses about what matters.

6.2 We test with few combinations

We have checked with Chrome only, and with no screen reader or mail program yet (section 5). If you use something else, such as Safari, Firefox, a screen reader, voice control, a switch, or a braille display, something may not behave as described here.

Way round: tell us what you use and what happened. If you are stuck meanwhile, section 9 lists other routes.

6.3 The bot check is not ours

The bot check on forms open to people who are not signed in is made and run by Cloudflare. It sits in a frame we cannot change. Most people are let through with no action or one tick, but it can refuse a browser it does not recognize, a privacy tool, or an unusual connection. Separately, Cloudflare's network may show its own challenge page to some visitors before they reach us at all.

Way round: everything behind the bot check can also be done by writing to us. For a removal request, a copyright notice or a dispute, use the email or postal address in that policy. For joining or signing in, write to accessibility@tillyard.org and we can work out another way to confirm it is you.

6.4 Table chat cannot be slowed for one person

Chat at a table is open throughout a session and reaches everyone at the table who is not Focusing. We cannot slow it down for one person without changing it for the others. The Fifteen, a fifteen-minute text conversation, has a clock that is the same for both people.

Way round: switch on Focusing and no chat reaches you. Nothing on the site depends on using a timer. Messages and threads have no clock and can be answered whenever you like.

6.5 A busy table can be a lot to listen to

At a lively table, many lines of chat may arrive in a short time. With a screen reader that can be more speech than is comfortable, and with a switch or voice control it can be hard to answer before the talk moves on.

Way round: pause live updates, read what arrived, and resume when you are ready. Set live pages to start paused under "Reading and motion". Choose a smaller table.

6.6 Passkey prompts belong to your device

When you create or use a passkey, the window that asks for your fingerprint, face, PIN or security key is drawn by your browser or operating system, so we cannot change how it looks. Some combinations of browser and assistive technology handle that window poorly.

Way round: you can sign in with a code emailed to your college address. For your protection, a session opened with a code alone is limited for a while: some sensitive actions, such as a data export, wait 24 hours. If that wait causes you a problem, write to us.

6.7 Sign-in codes run out quickly

A code works for only a few minutes, and only a few wrong tries are allowed. If reading your email and typing the code takes you longer than that, the code can lapse.

Way round: ask for another code; there is no penalty for doing so a few times. You can paste the code. If the time is still too short, write to accessibility@tillyard.org and we can work out another way.

6.8 Live rooms and instant delivery need scripts

Joining, signing in, writing, submitting, reporting and every form work without scripts. A live room in The Shop, and notes arriving the moment they are sent, need scripts and a kind of connection that some networks and older assistive tools block.

Way round: Notes works as ordinary pages that you reload. Scheduled tables, Tillyard Research, Pursuits, The Record, The Workbench and The Almanac do not need a live connection.

6.9 What members write is theirs

Papers, notes, profiles and table cards are written by members. A paper may use long sentences, undefined terms or headings out of order. A member may write a passage in another language, and it is not marked as such for a screen reader. A figure's description is written by its author and may be short or unclear.

Way round: if a published paper is hard to read with your assistive technology because of how it is laid out, tell us and we can ask the author or correct the structure. We do not rewrite an author's words.

6.10 Files made by your browser

"Save as PDF" in The Workbench and on The Record uses your browser's own print function. Whether the PDF it makes is tagged so that a screen reader can read it in order depends on your browser, not on us. We have also not checked the Word file the résumé builder exports with every screen reader.

Way round: the page itself is the accessible version, and every public record and paper has a web address you can give in place of a file. Tell us if a file comes out unusable.

6.11 Printed pieces and QR codes

The printable menu and table tents are designed for paper. A QR code is a picture.

Way round: every QR code is printed with the same address in text. The menu's content is also on the site as an ordinary page.

6.12 Calendar files

A calendar file for a table or a project session opens in your own calendar program. How that program presents it is outside our control.

Way round: the same day, time and time zone are written on the page.

6.13 Tables that move to a call

Tillyard has no audio or video of its own. A member who opens a scheduled table may paste a link to an outside video-call service. Whether that call has captions depends on the service and on the people in it.

Way round: nothing that counts on The Record requires joining an outside call. Everything that counts happens in text, on the site. You can ask the table's opener to keep the conversation in the table's text chat.

6.14 Long documents and wide tables

Some policies are long, and a few, such as the Data Retention Schedule, are mostly tables with several columns. On a small screen or at high zoom a wide table may need sideways scrolling inside its own frame.

Way round: each policy starts with a short summary and has a text-only copy. Write to us if you need a document in another form (section 9).

6.15 English only

The site and its documents are in English. We aim for everyday English, but some pages, the legal ones most of all, are harder to read than we would like.

Way round: each policy's "In short" is written to be read alone. If a sentence in a policy is unclear, ask us what it means at support@tillyard.org.

6.16 Email in unusual mail programs

Our email is laid out with tables, because that is the only layout old mail programs draw reliably. Those tables are meant to be ignored by screen readers. A mail program we have not checked may announce them.

Way round: switch to the text-only version, which every email carries. Almost everything we email is also in your notices on the site.

6.17 Days when parts of the site are paused

The site runs inside daily limits. On an unusually busy day it may switch off some parts for the rest of that day, such as new sign-ups or table chat, so that sign-in, reporting and the removal forms keep working. A pause can interrupt something you were in the middle of, which is harder to recover from if moving around the site takes you more effort.

Way round: drafts are kept. Reports, removal requests and disputes can always be sent by email.

7 No overlay widgets

We do not use an accessibility overlay: a third-party script, usually with a floating button, that claims to make a website accessible by itself.

• Overlays do not fix the underlying page. They sit on top of it.
• They often get in the way of the assistive technology a person already uses and has set up to suit them.
• A third-party script would also break two of our own rules: no outside scripts except the bot check, and nothing that watches how you use the site.
• In 2025 the Federal Trade Commission ordered one overlay company to pay one million dollars over claims that its product could make any site meet WCAG.

The adjustments we offer are built into the site (section 3.14) and store no identifier.

8 Tell us about a barrier

8.1 How to reach us

• Email: accessibility@tillyard.org
• Post: Tillyard, Accessibility, 10602 York Rd SW, Etna, Ohio 43062
• From the site: the "Accessibility" link at the foot of every page leads here.

You do not need an account. You can write on someone else's behalf.

8.2 What helps

Tell us as much of this as you are willing to:

• the address of the page, or which part of the site;
• what you were trying to do, and what happened;
• your browser and device, and any assistive technology you use;
• whether the barrier is stopping you from doing something that has a deadline, so that we can find another way first.

8.3 What we do not ask for

You do not have to tell us about a disability, and we do not ask for proof of one. A description of what went wrong is enough.

8.4 What happens next

1. A person reads it. Today that is the president, who runs the site.
2. If we need to know more, we reply with questions.
3. If the barrier is stopping you from doing something, we look first for another way for you to get it done (section 9), before we look at the fix.
4. We decide what to change. Barriers that stop people joining, signing in, reporting something, asking for a removal, or reaching their own data come first.
5. We tell you what we decided, including when the answer is that we cannot fix it, or cannot fix it soon, and why.
6. If the barrier affects other people and is not fixed quickly, we add it to section 6.

One person reads this mailbox, so we do not state a reply time. If your message concerns something with a legal deadline, such as a removal request, say so in the subject line, and use the address in that policy as well.

8.5 If you are not satisfied

Reply and tell us, or write to legal@tillyard.org with "Accessibility" in the subject line. In a company run by one person, the person who looks again may be the person who answered first. Section 12 explains that none of this affects your legal rights.

8.6 What we do with your message

We use it to answer you and to fix the problem. We may pass the technical details, without your name, to someone working on the fix. If you tell us about a disability, we use that only to help you and do not add it to your account. Messages to this address are kept for the period the Data Retention Schedule gives for correspondence. Reporting a barrier never affects your standing here.

9 Other ways to get something done

If a barrier stops you, we can usually get the same thing done another way. Where we need to be sure a request comes from the account's owner, we confirm it by sending a code to the address on the account. We do not ask for identity documents.

Some things we cannot offer. We cannot slow table chat for one person (section 6.4). We cannot sign in for you, or hand anyone's account to someone else. We cannot change another member's writing.

10 Other people's services and content

• Stripe. If you choose to leave a tip, the payment page is Stripe's, at Stripe's address. Its accessibility is Stripe's. Tipping is never needed to use anything here.
• Cloudflare. The bot check and any challenge page are Cloudflare's (section 6.3).
• Video-call services. A link to an outside call is the member's choice and the service's product (section 6.13).
• Links out. A DOI, a LinkedIn address, a listing on a government or commercial opportunities site, or a source cited in a paper leads to a site we do not control.
• Your mail and calendar programs. We design for them and cannot control them.

If one of these stops you doing something on our site, tell us anyway. We cannot fix another company's page, but we can often give you another route, and we can choose a different provider if one keeps failing people.

11 Taking part at your own pace

Nothing on the site rewards speed, and most of it has no clock at all.

• Reading. Choosing to read another member's work is voluntary. The reading form has no timer, and you can decline anything you are offered without giving a reason.
• Rounds. A round in Pursuits has published rules, which include its closing time. If a disability means the format or the timing does not work for you, write to accessibility@tillyard.org before the round closes. Where a change would not alter the task for the other entrants, we may be able to make it.
• Scheduled tables. If you hold a seat and need something from the table's opener, such as keeping the talk in text, you can ask them in the table's chat. If you would rather we asked, write to us.
• Editor's questions and revisions. If you need longer to answer the editor's questions or to revise a paper, say so. A paper that returns to draft carries no penalty.

These are things we can do, decided case by case. They are not entitlements, and we cannot promise a particular change.

12 Your rights

You may have rights under federal or state disability law. Nothing in this statement limits them, and writing to us first is not a condition of using them. We ask for the chance to put a barrier right because that is usually the quickest way to get you what you need.

13 Keeping this statement current

• We aim to review this statement, and the site against it, at least once a year, and whenever a new part of the site opens.
• The date of the last review is in section 5.6.
• When a barrier in section 6 is fixed, it comes off the list. When a new one is found and not fixed quickly, it goes on.

14 Changes to this document

The version number and effective date are at the top, and earlier versions stay available. Changes to sections 5 and 6 are corrections of fact and apply when posted.

15 Contact

• A barrier, or a request for another format: accessibility@tillyard.org
• General help: support@tillyard.org
• If you are not satisfied with our answer: legal@tillyard.org
• Post: Tillyard, Accessibility, 10602 York Rd SW, Etna, Ohio 43062

Questions about this document

support@tillyard.org

Legal notices

legal@tillyard.org

By post

10602 York Rd SW, Etna, Ohio 43062

For anything else, see where to send what.

Fingerprint of this text (SHA-256): 922566209f05f17defb5f707c7844dc90e86c762412580031b4ee80030bd5225