openlibhums / openlibhums/janeway

Consider Roman numeral use

Open
#4,223 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

a11y VPAT
Dominant language
Python
Stars
238
Forks
97
Avg merge
9d 1h
Merged PRs (30d)
8

Description

Roman numerals are difficult to make accessible, such that the general advice on how to do so, boils down to don't. This was noted during screen reader testing (#4194).

  • Sample 3, item 16. first section heading is correctly an H2, but the I. Roman numeral denoting it as the first section does not get read out as "one" but "I" get later for section 2, the "II." is read out as 2. This is a problem with the screenreader not being able to distinguish for single 'I' that it is a roman numeral. Similar issues are known with other single letter Roman numerals. See notes.
  • Sample 3, item 36. use of Roman Numerals within the text (not just as headings) to denote a list within the paragraph, for example: It might refer (i) to actual results, i.e., to the empirical impact—if that can be measured—that each lie actually has on the enterprise of human communication. Or (ii) it might refer and so on. The initial (i) is read as i and then the (ii) as 2 - see notes on Roman numerals.
  • Sample Other, item 11. Roman numerals are not just a screen reader A11y issue. There doesn't seem to be an accepted solution, with general advice being to limit their use. WC3 guidance is to avoid the use of Roman Numerals and unfamiliar symbols in text where possible.

We need to consider how to handle Roman Numerals. We could simply ban them from the platform, but I suspect it would be more acceptable to users for us to allow them in specific use-cases and have very specific ways to use them for those with work arounds to make that as accessible as possible, for example, section numbering and list numbering. Note this is not just a screen-reader issue, but roman numerals for numbering can be difficult across multiple types of impairment.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the screen-reader testing referenced in #4194 and review the cited Sample 3 and Sample Other items, along with the WC3 guidance mentioned here. The issue does not name implementation files or tests; work is complete only after the project decides which Roman-numeral use cases to support and records testable accessibility criteria.

Written by the indexing model from the issue text.

Assessment

Domain
accessibility, content
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.