Personal branding advice for engineers tends to assume a single kind of audience: recruiters and peers with fast connections, good eyesight and plenty of time to read. In practice, your profile, portfolio and talks are encountered by a much wider mix of people, and if your material is hard to use, some of them simply move on without telling you. The questions below are the ones engineers ask most often about building a professional presence that is open to everyone. The answers lean on observable good practice rather than on invented statistics.
Why would accessibility matter to a personal brand at all?
Because a brand is only useful if people can reach it. A portfolio that fails on a phone, a résumé that a screen reader cannot parse or a conference talk without captions limits who can engage with your work. Hiring managers, collaborators and learners differ in vision, hearing, language and device. Each barrier you remove increases the share of them who can see what you can do. That is a practical point, not a moral lecture.
What is the “imagined average visitor” problem?
It is the habit of designing for someone just like yourself. Most engineers are comfortable with small type, dark themes with low-contrast grey text, unlabelled icons and clever navigation. Those choices feel stylish to the creator. They can be unreadable to an older hiring manager, to someone with low vision, or to a reader in bright light on a modest phone. Naming the assumption is the first step in correcting it.
What are the most common problems on engineer portfolios?
The recurring ones are easy to list. Text with weak contrast. Images of code, which cannot be read by assistive software, resized or searched. Links labelled “here” or “more”. Videos with no captions. Menus that cannot be used with a keyboard. Project descriptions packed with unexplained abbreviations. Pages that load slowly because of heavy scripts. None of these requires advanced skills to fix, which is why they stand out as missed opportunities.
How should I write project descriptions?
Lead with the outcome in a sentence or two, then give the context and your role, then the technical detail. Explain abbreviations once. Prefer short paragraphs and real headings. If you describe a containerisation project, for instance, a non-specialist should understand what problem it solved, even if they never read the technical section. Posts that explain technology to newcomers in plain terms, such as a short list of everyday container missteps for people starting out, show the register that works: friendly, precise and free of gatekeeping.
What about code samples?
Paste code as text, not as screenshots. Use a readable font size and strong contrast. Briefly describe what the sample does before showing it, so that a person using a screen reader knows what to expect. If you include a diagram, add a text description beneath it. The same applies to architecture drawings, which carry meaning that would otherwise be lost entirely for some readers.
How do I make talks and videos inclusive?
Caption every recording and publish a transcript. Describe on-screen actions aloud as you perform them. Share slides in advance in a text-friendly format, and avoid relying on colour alone to convey meaning. Captions are valuable beyond the people they were designed for: viewers in noisy places, viewers in quiet offices, and viewers watching in a second language all use them. A transcript also makes your talk searchable, which does more for discoverability than most people expect.
Is there evidence that this helps?
It is wise to be careful here. There is no definitive study that proves inclusive portfolios win more job offers, and anyone quoting a precise figure should be asked to show the source. What is well established is narrower: accessibility guidance from standards bodies is mature, plain language is widely recommended, and each barrier you remove demonstrably widens the group that can use your page. The sensible position is to treat these as low-cost improvements with plausible benefits, not guaranteed returns.
How should I explain concepts in articles?
Define terms at first use, give one example per idea, and keep sentences short. Our explainer on how containers differ from virtual machines for learners demonstrates the approach: a complex comparison made approachable without watering down the content. Readers with less background are not less intelligent; they simply lack your context.
Should I publish an accessibility note?
A short one is worthwhile. It tells visitors which needs you have catered for and where to flag a failure, which signals care and professionalism. This is routine among web practitioners; cmsGalaxy, a team doing website development and SEO that publishes its own accessibility statement, is a useful example of the format. Keep yours honest: list what you test, name what you have not fixed yet, and promise only what you will follow through on.
How do I test my own site quickly?
- Zoom the browser to twice the normal size and see whether the layout still works.
- Put the mouse aside and move through every link with the keyboard.
- Check the contrast of body text against its background.
- Look at the site on a phone over a slow connection.
- Ask a friend outside tech to explain what you do after reading your homepage.
What is the simplest first step?
Rewrite your bio. Make it two plain sentences about what you do and who it helps, free of buzzwords. Put it at the top of every profile, then check that the text can be read aloud and understood without context. From there, work down the list: captions, descriptions, labels, contrast. Small changes made steadily outperform a grand redesign that never ships.
The principle behind all of it is the same. Build your public profile around the visitor you would normally overlook, and the typical visitor is served better as well, and the effort quietly tells everyone who visits that you think about people other than yourself.
