Actions

Work Header

Rating:
Archive Warning:
Fandom:
Additional Tags:
Language:
English
Collections:
A Guide to Coding and Fanworks, Fanfiction Reference Works
Stats:
Published:
2020-11-07
Words:
1,611
Chapters:
1/1
Comments:
5
Kudos:
74
Bookmarks:
83
Hits:
2,367

Conlangs and Accessibility

Summary:

A Quick Guide to Making Translations Accessible on AO3

Work Text:

Introduction

Handling constructed languages, and even multiple languages within the same work, is challenging. How do you make sure your translations are easily accessible for those who need them without being obtrusive to those who don't? What do you do if most of your dialogue is in a different language compared to just a few words here and there? How do you accommodate the full spectrum of devices people use to read fics?

Hopefully this guide helps you make your translations as accessible as possible.

Inline Methods

AKA the Definition (dfn) Method

The simplest method of including unobtrusive inline translations is to use the dfn element with the title attribute which allows readers to hover over the text and read a tooltip translation.

<dfn title="Your translation goes here.">Text to be translated goes here.</dfn>

The result:

Text to be translated goes here.

The biggest drawback of dfn is that it requires some sort of on-screen pointer to work (i.e. it's not mobile-compatible).

There are other methods which employ CSS to provide on-click/-tap translations which are mobile-compatible. Simbeline has written an excellent guide on mobile-friendly tooltip translations that is screen reader compatible and dramatically simplifies the coding you have to do compared to other popular CSS methods in use.

Mobile Browsers and Keyboard Navigation

AKA the Hyperlink Method

The simplest method that is mobile- and keyboard-compatible is to use in-text hyperlinks with an appendix of translations. Note that there is a length limit for endnotes on AO3, so unless you're only translating a few words, I recommend sticking your appendix at the end of the work/chapter itself (even though having it in the endnotes would be visually more pleasing and not inflate your word count).

The greatest strength of the hyperlink method is that it can easily be adjusted to better support screen readers. As a result, this is the translation method I consider to be the best and most accessible, even though it does require a fair amount of coding.

I also recommend linking the entire phrase to be translated rather than having a linked reference at the end of the phrase. There are several reasons, but the most important is that linking the whole phrase gives the people using screen readers the option to reliably skip past the gibberish their readers will spit out.

The hyperlink method uses the anchor tag and the href, name, and id attributes. Both name and id are required for this method to work, even though they will have identical properties, and this is enforced by AO3's parser. If you forget the name or id in one tag, the parser deletes the property entirely.

<a href="#translation" name="#text" id="#text">This is the text to be translated.</a>

<h2>Translations</h2>

<a href="#text" name="#translation" id="#translation">This is the translation.</a>

The name/id can contain numbers and letters. Avoid special characters and punctuation other than dashes (-) and underscores (_). Additionally, the name and id must be unique for each link.

Now, while the above code works, the one major downside is that it brings the reader back to the start of the first link, forcing the reader to skim through the untranslated text again to get back into their reading. This is particularly inconvenient for someone using a screen reader.

If you want to create a more immersive experience where the translation link jumps to the end of the first link, you will need to add a second anchor tag after the untranslated text and make that the return point with name and id.

<a href="#translation">This is the text to be translated.</a><a name="#text" id="#text"></a>
<a href="#second">This is more text to be translated.</a><a name="#more" id="#more"></a>

<h2>Translations</h2>

<a href="#text" name="#translation" id="#translation">This is the translation.</a>
<a href="#more" name="#second" id="#second">This is the second translation.</a>

For a real-life demonstration of how this method works, you can check out my work Su'cuy Gar where the majority of the dialogue and a few in-line terms were written in Mando'a.

Screen Readers

Hyperlink Method + ARIA Attributes

If you're truly committed to making your work screen reader accessible, there are additional bits of code called ARIA attributes which exist specifically for accessibility. ARIA attributes can be added to any HTML tag and are particularly useful for links. Using ARIA attributes also requires minimal coding if you are already using the hyperlink method for your translations.

Unfortunately, ARIA attributes are not supported on AO3 at this time, but I recommend looking them up regardless in the hopes that one day they will be supported. I particularly recommend checking out the aria-label, aria-labelledby, aria-describedat, and aria-describedby attributes and use cases.

Keyboard and Low-Vision Link Navigation

Hyperlink Method + CSS BORDER Property

For folks with limited dexterity who can't use a mouse or tiny touchscreen, keyboards are often the tool of choice for navigating the internet. The presence of multiple links close together can be difficult to navigate by keyboard, especially when the links are not visibly differentiated while focused on. This lack of link visibility also affects low-vision readers.

This is very easy to fix by using the a:active, a:focus, and a:hover CSS pseudo-classes and the border property in a custom work skin.

#workskin a:active,
#workskin a:focus,
#workskin a:hover {
border: 3px solid;
margin: -3px;
}

Hover or press and hold this sentence to see the result. This link should be clearly separate from the other links. The -3px margin is there to offset the size of the 3px border. Without it, the border would push all the text after it over by 6px, which can be a bit visually jarring.

Streamlining the Process

AKA Minimizing the Amount You Have to Code

So you've got a lot to translate and even more to code, but you've never coded this much before. Or, you find that spellcheck is an essential tool and so do all your fic writing in a word processor that even does the fancy quotes for you but makes using simple quotes a nightmare.

That's okay. There are ways to automate the process so you don't have to manually add in the same stuff over and over again, and you don't even need a special program or app to use one of them.

Method 1: Find and Replace

Find and Replace is thankfully a standard feature in most text editors and word processors. With a bit of planning, you can use it to cut down dramatically on the amount of coding you have to do.

My personal favorite method is to use 2-4 special characters I know I will not be using elsewhere in the document. One character is used to mark the start of the hyperlink while the second is used to mark the end. Once the document is complete and revised, you can then run Find and Replace to add in the basic coding.

^This is the text to be translated.&

<h2>Translations</h2>

%This is the translation.+

Find: ^
Replace: <a href="#">

Find: &
Replace: </a><a name="#" id="#"></a>

Find: %
Replace: <a href="#" name="#" id="#"></a>

Find: +
Replace: </a>

Afterwards, you would only need to add in the unique name and id (which are the same) plus the link reference (the name/id of the translation) to each instance.

<a href="#">This is the text to be translated.</a><a name="#" id="#"></a>

<h2>Translations</h2>

<a href="#" name="#" id="#">This is the translation.</a>

Method 2: Use a Code Editor

Code editors are essentially glorified text editors with several features that make coding so much easier. I strongly recommend using one if you write a lot of dialogue in a conlang because autocomplete, automatic closing tags, and multi-point selection are beautiful time-saving things.

Not all code editors have all those features, however, so be sure to look for them specifically if none of the code editors I recommend below work out for you.

Atom

The Atom text editor is free and open source. It's also very reliable while also being incredibly customizable. It works on Windows, Mac, and Linux, in addition to Chrome OS with a bit of finagling.

Sublime Text 3

The Sublime Text 3 code editor is considered by many to be the best code editor around. It is lightweight and customizable with a lot of useful coding features. Its one downside is that it is not free, although there is an indefinite free preview available. If you really like using it, though, support the developers and drop the one-time fee of $80 (at the time of writing) for the full license.

Sublime Text 3 is available on Windows, Mac, and Linux.

Visual Studio Code

Unlike the previous two recommendations, Visual Studio Code is a full Integrated Development Environment (IDE). What this means is that Visual Studio Code has all the features you'll need and then some as it is designed to code applications from the ground up. Due to the sheer number of features available, it's not the easiest to learn or initially use, but if you happen to code in other languages and want an environment that supports HTML in addition to whatever your language of choice is, Visual Studio Code is an excellent and completely free option.

This is what I personally use because being able to edit the HTML for my fics in the same application I code in is convenient, and Visual Studio Code's HTML support is some of the best I've experienced.

Like the other two, Visual Studio Code works on Windows, Mac, and Linux.