Skip to main content

Commitment

Peer Academics publishes research that is free to read, and content that cannot be read by everyone is not free to read. The Publisher's aim is that every part of peeracademics.com — the articles, the pages describing the journal, and the system you use to submit and review — can be used with a screen reader, with a keyboard alone, with magnification, and with text and color settings of your own choosing.

The standard the journal works to

The target is the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. In practice this means: pages built from semantic HTML with real headings, lists, and tables; every interactive element reachable and operable from the keyboard, with a visible focus indicator; text that reflows and remains readable when enlarged; sufficient contrast between text and background; form fields with labels and errors described in text; language declared so that screen readers pronounce content correctly; and no reliance on color alone to convey meaning.

This is a statement of the target, not a claim of verified conformance. No external accessibility audit has been carried out, and the journal does not claim that every page currently meets Level AA. It claims that Level AA is the standard against which failures will be judged and fixed.

Known limitations

  • PDF galleys. Published PDFs are produced from files authors supply. A PDF built from an ordinary word-processor file is often untagged: its reading order may be wrong for a screen reader, its tables may not be navigable, and its figures may lack alternative text. Until the journal's production process guarantees tagged PDFs, treat PDF accessibility as unreliable.
  • Figures and equations. Alternative text for figures depends on authors supplying a description, as Figures and Tables requires. Mathematical notation rendered as an image carries no accessible equivalent unless one is provided.
  • The editorial interface. The submission and review workspace is Open Journal Systems, software maintained upstream by the Public Knowledge Project. The Publisher configures it but does not write it, and cannot fix an accessibility defect in that software directly. Defects reported to the journal that lie upstream are reported onward to the developers, and you are told that this is what has happened.
  • Author-supplied supplementary files. These are published as submitted, are not copyedited or converted, and may be in formats that are not accessible.
  • Third-party content. Material on sites the journal links to is outside the Publisher's control.

What authors are asked to do

Accessibility of an article begins with the manuscript. Use the heading styles in your word processor rather than bold text to mark structure; supply a description of every figure; build tables as real tables with header rows, not as pictures; give links meaningful text rather than a bare address; and do not use color as the only way of distinguishing data in a chart. These requirements are in the Author Guidelines, and they are the single largest factor in whether a published article is usable.

Reporting a barrier

If any part of the site stops you from doing something, tell the journal. Write to [email protected] and include:

  • the address of the page, or the name of the article;
  • what you were trying to do and what happened instead;
  • the assistive technology, browser, and operating system you were using, if you know them.

You will receive an acknowledgment normally within five working days, with an assessment of the problem and, where it can be fixed by the journal, a timescale. Where the defect is in the underlying software, you will be told that and told what has been reported upstream.

An accessible alternative is available on request. If a published article is not usable for you in the form it is published, ask, and the journal will supply the full text in an alternative format — for example an HTML or plain-text version, or the author's source file — at no charge. This applies to any article, and you do not have to explain why you need it.

If you have reported a barrier and are not satisfied with the response, write to [email protected], which is handled separately from technical support.

This statement is reviewed when the site changes materially, and updated when a limitation listed above is removed.