this post was submitted on 18 Nov 2023
88 points (96.8% liked)
Programming
17524 readers
312 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Accessibility and internationalization first. A lot of projects start without it and tack it on later. It's so much better to have good roots and promote diversity and inclusivity from the start.
Could you elaborate in what context and to what extend? I can agree that bigger companies with large user-bases should have a focus on accessibility and internationalization -
But generally a lot of projects start with just one dev solving a problem they have themselves and make their solution Open-Source. Anecdotally, I'm dumping my solutions on Github that are already barely accessible to anyone somewhat tech-illiterate. No one is paying me anything for it. Why would I care whether it's accessible or internationalized for non-English speakers?
Internationalization isn't about the translation. It's about not hard coding the strings that display. Putting them somewhere that is easy to swap out would allow users to provide their own if they wanted.
As a solo developer, some things are out of scope like writing translations or ensuring full compliance with accessibility standards. What's important is to have some knowledge of what things block progress in these areas. For example, not treating all strings like ASCII, or preferring native widgets/html elements as those better support accessiblity tools.