An App Development Company in Washington, DC That Sorts Every Screen by Language

Updated November 2026 · Written and maintained by the Progression Agency strategy team

A nonprofit funded by a District agency launches an app for families to enroll in a program, and the enrollment screen is in English only. Under the District’s Language Access Act, an enrollment form is a vital document, and a grantee that serves the public has to meet the same language duties as the agency that funds it. The app also has to record which languages its users need. An app development company in Washington, DC building for that world sorts every screen before it designs one. Progression is based in New York, builds for District organizations remotely, and offers on-site sessions on request.

An enrollment screen in English only

A family opens an app from a nonprofit that a District agency funds. The first real screen asks for a child’s name, a parent’s email and a ZIP code, and every word on it is English. The card below is hypothetical, and it carries more weight than it looks.

The District’s Office of Human Rights lists claim, application and enrollment forms among its examples of vital documents, and it says vital documents may be in electronic or print form. A screen that collects the same information as a paper form does the same job, so the test is not whether the screen looks finished. The test is whether someone who reads Amharic, Korean or Spanish can finish it.

• Treat every screen that collects or confirms a person’s information as a candidate for translation.
• Ask the funding agency how it classifies each screen before design starts.
• Store the language the person prefers the first time they say it.
• Plan the report the funder will ask for while the first screen is still a sketch.

What an app development company in Washington, DC must know about the Act

The Language Access Act of 2004 applies to District government agencies called covered entities. The Office of Human Rights (OHR) says covered entities must name a point of contact, collect data on the languages they encounter, translate vital documents, offer interpretation, train staff, post signage and file a yearly report. It also says covered entities are responsible for making sure their grantees and contractors meet the same requirements. That last line is why a nonprofit’s app lands in this territory. Read the OHR language access page for covered entities, and confirm with the funding agency which duties pass down to your organization.

How does the threshold work?

OHR sets each covered entity’s threshold at the lesser of two numbers: 3% of its constituent population or 500 people. If 3% comes to fewer than 500, that smaller number is the threshold. If it comes to more, the threshold is 500. A language spoken by at least that many of the entity’s constituents who have limited or no English is a threshold language, and vital documents must be available in every one of them.

The six languages most often encountered

OHR reports that covered entities encounter a wide variety of languages, with Amharic, Chinese, French, Korean, Spanish and Vietnamese the top six. That list is a useful place to start, not the answer for your program. Your own data decides your threshold languages, and your funding agency can tell you which ones it expects.

Why does the app have to carry the duty?

OHR also says that existing databases, applications and tracking systems must be updated with fields that capture which languages are encountered and how many customers speak each. An app is a tracking system and an application at once. Built well, it does the counting as a side effect of people using it.

The screen inventory

Here is the inventory for a hypothetical app that lets families enroll in a funded program. Each screen is sorted three ways: is it a vital document, does it carry a tagline, and does it log the language. The sorting follows OHR’s own examples of vital documents. Where a screen could go either way, the safer build is the one in the second column, and the funding agency has the last word.

Screens that are vital documents

OHR’s list includes complaint, consent, release and waiver forms, claim, application and enrollment forms, notices about reducing, denying or ending services, time sensitive notices, notices of rights and responsibilities, and notices that free language help exists. In an app those become the enrollment form, the consent screens, status and decision notices, deadline reminders and the help screen. These get a full translation into every threshold language, and they have to be as easy to find as the English version.

• Translate the whole screen, including labels, hints, errors and the button text.
• Put the language choice where a first time user sees it without scrolling.
• Keep the translated version as easy to reach as the English one.
• Re-check the translation whenever the English screen changes.

Screens that carry a tagline

Where a screen is not vital, OHR calls multilingual taglines the best practice. A tagline is a short line that tells a person how to ask for help in their own language. In an app it sits in the footer or the help area of every screen, and it points to the interpretation line. OHR has published its own sample taglines, and your funding agency can say whether to use them.

• Place a tagline on every screen that is not fully translated.
• Link the tagline to the help screen, not to a generic page.
• Test the link on a phone, where most users will see it first.

Screens that must log the language

Every screen where a person is served counts as a contact. OHR’s grantee guide says each interaction counts as an encounter, and it names online applications among the points of contact to cover. So the app logs the preferred language and the mode of service on every flow that touches a person, even the ones that are not vital documents.

What a build like this costs

Cost follows the number of screens, the languages and the integrations, and language support adds design and testing time on every screen. Progression quotes after a written scope and publishes no Washington price. The bands below are published market figures that run from the typical low to the published high.

Translation, interpretation and testing with real users are not in these bands, and your funding agency may set its own vendors. For what drives app prices in general, see app development cost.

Fields that capture the language

OHR’s guidance is direct: the system has to carry fields for which languages people use and how many people use each. A field added at the end of a project is a patch. A field designed on the first day becomes the report on the last.

The six cards above are the minimum data model for the report. The preferred language belongs to the person. The language encountered belongs to the contact, because a person may ask for different help on different days.

Preferred language at sign up

Ask once, on the first screen, and use plain words. List the languages by their own names so a reader finds theirs. Allow a change at any time from the settings screen, and carry the change to every message.

The encounter log

Each contact adds one row: date, language, mode of interpretation, point of contact and program. Nobody types the totals. The log is the source, and the report is a count of it.

• Record the language the person prefers, not the language a staff member guessed.
• Use fixed lists for mode and point of contact, so the totals add up.
• Keep English as a value too, so a share of all contacts can be seen.
• Never overwrite an old row when a preference changes.

Threshold languages, not a fixed list

A fixed list of five or six languages is a starting point. The language set follows the organization’s own threshold, and it changes as the log fills in. An app that stores translations as separate, named versions can add a language without a rebuild.

Text grows and scripts differ

Design the first screen with the longest language, not the English one. A button that fits “Submit” may not fit its translation, and a script that is not Latin needs its own font and spacing. Test each language on a small phone before it goes to a family.

Which languages go in first?

Start with the threshold languages your data shows, add the ones your funding agency names, and use OHR’s top six as a check. A language that shows up in the log without a translation is the next one to add.

• Keep every screen’s text in a language file, not in the layout.
• Test with real users who read each language.
• Name each language in its own script on the chooser.
• Hold a short list of languages queued for the next release.

Mobile app development in DC for grantees who certify

OHR’s grantee and contractor guide says grantees certify in writing that they will meet the Act’s requirements. It says the District agency that funds the grantee must put the language access requirements in the contract or memorandum of understanding. For a nonprofit commissioning an app, that means the funder may ask for proof of what the app does.

What should the app’s documentation show?

Write down the screen inventory, the language list and where each translation came from, the fields in the log and a sample report. Add the date each translated screen was last checked. The grantee decides what to certify, and counsel or the funding agency decides what the certification means. The documentation just makes the facts easy to find.

• The screen inventory, sorted the way this page sorts it.
• The language list and the dates each translation was checked.
• A diagram of the fields the app stores.
• A sample quarterly report with made up counts.
• The name of the person who owns each translation.

What should the funding agency be asked?

Which screens does the agency treat as vital? Which threshold languages does it expect? What report format does it want, and how often? Who reviews translations? Get the answers in writing before design starts, so a change in scope never looks like a change in duty.

Push messages and help screens in the user’s language

A reminder is a time sensitive message, and a deadline notice may be a vital document. Notices, reminders and errors should follow the language stored on the profile, not the language of the phone. People often share phones or set them to a language they do not read well.

What happens with a language not yet translated?

When a notice has no translation for a person’s language, never send English alone. Show the tagline with the phone number for free interpretation, log the contact and flag the gap to the team that owns translations.

Interpretation by phone from inside the app

OHR says covered entities offer interpretation in person or by phone, through a bilingual staff member, an in person interpreter or the District’s contracted telephone service. A help button that dials the organization’s interpretation line puts that service one tap away, and the app logs the contact and the mode.

• Send reminders in the stored language and at a sensible hour.
• Keep message texts in the same language files as the screens.
• Show the interpretation number on the help screen and in every tagline.
• Log each call the app starts.

The quarterly language report, built in

OHR’s grantee guide asks grantees and contractors that face the public to collect and report encounter data quarterly from every point of contact, including hotlines, walk in facilities, mobile units, community events and online applications. It lists three parts for the report: the languages encountered, the number of encounters per language and the mode of interpretation.

The report should be a button, not a spreadsheet project. Build the export to match the funding agency’s report layout once, test it with last quarter’s data and add a reminder before the quarter closes. Our app development agency page describes how builds like this are scoped.

What should be checked before the first quarter ends?

Run the export on test contacts and compare the totals by hand. Check that every point of contact appears, including the app. Confirm with the funding agency that the layout is the one it wants.

• Run a test export two weeks before the quarter closes.
• Compare the totals to a hand count of a small sample.
• Keep each quarter’s file as it was sent.
• Name who sends the report and who checks it.

Who owns the translations after launch?

A translated screen is not finished the day it ships. The English text changes, a program adds a field, a notice gets a new deadline, and each change needs a matching change in every threshold language. Without an owner, the English screen moves on and the translations quietly fall behind.

• Name one person at the grantee who approves every translation change.
• Keep a change log that shows the date each language was last checked.
• Freeze a vital screen’s English text until its translations are ready.
• Ask each reviewer to sign off by language, not once for the whole app.

Related services and guides

Pages that sit beside this inventory:

• App development agency
• App development cost
• Government software development
• Nonprofit software development
• A page for a PR firm in Washington, DC covers the communications side of District work.

Frequently asked questions