One thing building Telescopo Markdown Studio has changed for me is that accessibility cannot be something I add later. It is too close to the actual experience of using the product. If the text is difficult to read, if the contrast is wrong, if the app ignores the way someone has configured their Mac, or if a person has to fight the typography before they can think about the document, that is not a separate accessibility issue sitting off to the side. That is the product being worse than it should be.
I used to think about accessibility mostly as a responsibility, which it is, but that framing can accidentally make it sound external to the craft of the software. Build the app, ship the features, then make sure the accessibility box is checked. The more time I spend with Telescopo, the less that separation makes sense to me. A writing and reading app is made out of text, contrast, rhythm, structure, controls, keyboard behavior, system preferences, and the way all of those details feel after someone has been looking at a document for an hour. Accessibility is not downstream from that work. It is inside it.
Markdown Is Not Disposable Text
Markdown has a strange reputation because the syntax is simple. It can look like plain text with a few symbols sprinkled around, so it is easy to underestimate the weight of the documents people create with it. In practice, Markdown ends up holding READMEs, technical specs, research notes, meeting notes, study guides, product requirements, release plans, AI-generated reports, architecture documents, and personal drafts that people keep open while they are trying to do real work.
Those files are not always glanced at for a few seconds. They are reviewed, revised, searched, compared, exported, and returned to again and again. A developer reading a README is trying to understand a system. A student reading a study guide is trying to remember something. A founder reading a product spec is trying to make a decision. A researcher reading notes is trying to hold a chain of thought together. In all of those cases, the Markdown app is not merely rendering text. It is becoming the surface the person is thinking through.
That changes the standard. If a document app makes long text tiring, the app has failed in a way that does not always show up as a crash or a broken feature. The button may work, the parser may be correct, and the export may succeed, but the software is still imposing a cost on the user every time their eyes have to work harder than they should. A writing app that fights your eyes is worse software.
The Mac Already Knows Something About the User
One reason native Mac software matters to me is that the Mac is not an empty canvas. People have already told the system things about how they want software to behave. They choose Light or Dark Appearance. Some enable Increase Contrast. Some tune display settings, text size, input behavior, and accessibility preferences because those settings make the machine more comfortable or more usable for them. A native app should listen to that before it invents its own little universe.
Telescopo supports macOS Increase Contrast because stronger visual separation is not a decorative variant of the interface. For some users, it is what makes headings, links, controls, document boundaries, tables, diagrams, and editor surfaces easier to distinguish. For Markdown especially, structure matters. A document is full of nested meaning: headings, lists, quotes, code blocks, tables, links, task states, and diagrams. Better contrast can make that structure faster to scan and less exhausting to hold in your head.
Light and Dark Appearance support belongs in the same conversation. A bright room and a late-night review session are not the same environment. A Mac app that treats them the same is asking the user to adapt to the software instead of the software adapting to the context. Telescopo has its own themes and personality, but it still needs to respect the larger system it lives inside. That is part of making the app feel like it belongs on the Mac rather than merely running there.
This is also why Apple's Human Interface Guidelines continue to matter to me. Not because guidelines solve taste, and not because every app should look identical, but because platform behavior carries meaning. Users should not have to relearn the fundamentals of their machine every time they open a tool that claims to be native.
Font Choice Should Not Be a Luxury Feature
The product decision I feel most strongly about is making dynamic font selection available to free users. Telescopo can use fonts installed on the Mac, including coding fonts, reading fonts, dyslexia-friendly fonts, and other accessibility-focused typefaces a user may already rely on. That matters because there is no universal perfect font. Comfortable reading depends on the person, the display, the text size, the document, the lighting, and the work being done.
It would be easy to treat font selection as a Pro feature because customization often gets monetized that way. I understand the logic, but I do not think it is right for this category of control. If a typeface makes Markdown easier for someone to read, that control should not be locked away from the person who needs it. A beautiful theme pack, advanced export workflow, template system, Live Monitoring, or AI-assisted review can be part of a paid workspace. Basic readability should not feel like a toll booth.
This is where accessibility becomes very practical. A user who reads better with a dyslexia-friendly font does not need a philosophical argument about inclusive design in that moment. They need the app to let them use the font that works. A developer comparing code blocks may need a monospace font with clearer punctuation. A writer reviewing a long essay may want a softer reading face. A person working on a small laptop may want a different font and width than someone working on a large display. These are not cosmetic preferences in the shallow sense. They change whether the work feels possible, fluid, and sustainable.
Accessibility and Visual Craft Are the Same Conversation
The more I worked on Telescopo's themes, the harder it became to separate accessibility from visual craft. A theme is not successful because it looks good in one screenshot. It has to hold up across headings, paragraphs, links, lists, code blocks, syntax highlighting, Mermaid diagrams, LaTeX math, tables, callouts, editor surfaces, preview surfaces, selected states, muted labels, and exported output. That is where design stops being decoration and becomes product engineering.
Code syntax colors are a good example. They can be attractive in isolation and still fail inside a real document. If two colors are too close, the distinction disappears. If a color is technically readable but unpleasant after a few pages, the document becomes tiring. If the highlighted code looks disconnected from the surrounding theme, the app starts to feel assembled rather than designed. Contrast, hierarchy, and color relationships affect comprehension, not just taste.
Mermaid diagrams made this even more obvious. A diagram has its own figure and ground. It has lines, fills, labels, arrows, clusters, generated colors, and sometimes assumptions that were never made with your app's theme in mind. A diagram that works on a light background can become muddy on a dark background, and a diagram that survives dark mode can still fail for someone who needs stronger contrast. Supporting diagrams well forced me to think about light and dark rendering separately, careful inversion, user-adjustable backgrounds, and dedicated high-contrast themes as part of the same product problem.
That is the part I want to carry forward into everything I build at Bad Command AI. Accessibility should not be treated as a parallel checklist that competes with polish. The polish is incomplete if the app ignores readability. The craft is incomplete if the system preferences do not matter. The feature is incomplete if the person who needs a more comfortable font cannot use one.
Still Learning
I do not want to overstate this. Telescopo is not perfect, and I am not claiming that every accessibility problem is solved because the app supports Increase Contrast, Light and Dark Appearance, high-contrast themes, and free dynamic font selection. There is still more to learn, more to test, and more to improve. That is part of the work. The important change for me is that accessibility no longer feels like a separate track from building a better app.
It belongs in the same conversation as performance, privacy, native Mac behavior, visual grammar, document rendering, and the small interactions that make software feel right. If Telescopo opens a document quickly but makes it uncomfortable to read, that is not good enough. If it renders Markdown beautifully for one person but ignores the settings that make another person's Mac usable, that is not good enough either.
The direction I care about is simple: better software should feel better for more people. Not as a slogan, and not as a marketing category, but as a practical standard for the work. A Markdown Studio should help people think, write, read, review, and understand without forcing them to wrestle the interface first.
If you care about Markdown tools that treat readability, native Mac behavior, themes, contrast, and font choice as part of the same product experience, Telescopo Markdown Studio is available at telescopo.app. The Telescopo resource on accessible Markdown writing on Mac also covers the current feature set in a more direct product format.
References: Telescopo Markdown Studio, Accessible Markdown Writing on Mac with Telescopo, and Apple's Human Interface Guidelines.
