You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
For the specific conflict between ASCII characters and roman numerals, we could recommend the use of the Unicode characters (as one would do for other numeral systems) which should be more explicit: https://en.wikipedia.org/wiki/Numerals_in_Unicode
To get this working, what we need is to be able to distinguish roman numerals from text - which isn't something we can do reliably from context as as that is exactly the problem the screen-readers are having. So the solution is to make it a human problem - i.e. when typesetting to have the roman numerals marked up as such. We need the roman numeral i to be distinguishable from all other i characters. If the Roman numeral is in unicode, then that would be distinguishable in the code, and we can format it however we like when rendered to the page.
Actions:
moving this to Phase 2 as it is going to require a change in user behaviour (typesetters to put roman numerals in as unicode).
we will facilitate this by providing a document which maps the roman numeral to the unicode.
modify the templates so that when the JATS is processed, unicode roman numerals are then converted back to normal text, but with a span around them that provides a text alternative.
Roman numerals used in lists (within <ol> tags) may need to be handled differently - as these should be encoded as lists first, rather than as the individual numerals anyway.
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).
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.
The text was updated successfully, but these errors were encountered: