Creating an Accessible Istanbul Metro Map for Screen Readers

An accessible Istanbul Metro map for screen readers should do more than describe a colourful diagram. It should let someone understand where a service goes, identify a station, work out an interchange and choose a direction without needing to see the page. That matters in Istanbul, where lines cross the Bosphorus, stations can have several entrances, and a visually compact network can hide several complicated decisions.

The goal is not an audio version of every line and station crammed into one announcement. It is a structured companion to the visual map: predictable headings, keyboard-operable controls, meaningful text and a route sequence that a screen reader can browse at its own pace. The visual map can still support quick reference and travellers with limited vision.

This work also has value beyond Turkey. Australian transit agencies and travel platforms already work in a market shaped by major city networks, disruption alerts and familiar fare products. Their accessibility practice offers useful parallels, even though Istanbul’s geography, station names and operating arrangements are different.

The most reliable approach combines verified network information with testing by people who use assistive technology. Start with the information a passenger needs to make a safe transfer, then choose the smallest amount of interface needed to deliver it. A downloadable text list helps when an interactive map is slow or incompatible with a device.

Start with the network data

The source of truth should be the operator’s current station register, line diagram and accessibility information, not an image found through a search engine. Capture each station’s unique identifier, official name, coordinates, line memberships, sequence and interchange links. Keep the source date with the dataset so a hurried editor can distinguish a missing record from a temporary closure.

Station order is essential. A screen reader should be able to follow “M2, Taksim, next Şişhane” without the station’s visual position determining what is announced. If official IDs are absent, add internal IDs that never depend on a map position. Record aliases, entrances, terminus names and direction so “which way” has a precise answer.

Give stops consistent names

A station can appear differently on signs, announcements, ticketing systems and maps. Establish a naming policy with the operator and store each accepted form as an alias. A passenger should be able to find a station by its Turkish name, its commonly used English name where one exists, or a distinctive interchange name, then reach one canonical record.

Names also need to sound clear when spoken. Use plain-language labels, expand unfamiliar abbreviations in text, and keep the announced form stable. Include the line identifier before the station name, but avoid repeating the line after every stop if that creates long, repetitive announcements. Screen readers may pronounce Turkish characters differently, so those names need testing with the intended language settings.

Design around screen reader navigation

Build the page around semantic headings, lists and links before adding custom widgets. A passenger should be able to skip to the map controls, move between lines, and return to the same position after opening station details. Visible focus must remain obvious, and every control must work from the keyboard alone.

Labels should describe actions and destinations, such as “Open Kadıköy station details”, rather than “More”. Announce updates only when they matter, for example a selected line or a changed route, and avoid using an ARIA live region to repeat large chunks of network data. A native list or well-tested disclosure pattern often handles this more reliably than a simulated grid. Test with VoiceOver, TalkBack, NVDA and JAWS.

Preserve meaning beyond colour

Colour helps many passengers scan a network, but it cannot be the only carrier of information. Keep line colours in the visual design while also identifying lines by number, using distinct patterns or symbols, and explaining interchange relationships in text. Ensure contrast between labels and backgrounds meets the relevant accessibility guidance.

A single image needs a concise alternative that states its purpose, not a long description of every coloured route. The full station sequence belongs in HTML beside the graphic, where it can be navigated one item at a time. For a downloadable PDF, use tagged headings, real text and meaningful reading order. An untagged image of a metro map may look correct on screen yet provide almost nothing to a screen reader.

Tactile diagrams help some low-vision passengers, but they do not provide the same structured route relationships to screen-reader users. A raised-line map can complement an accessible digital map rather than substitute for it.

For a large illustrated network diagram, automated metadata extraction can support an initial descriptive pass, but every suggestion needs review against the route data. Automation can help reveal missing image descriptions; it cannot determine whether a transfer instruction is accurate or a station name will be understood.

Add practical route guidance

Station lists answer where, but a journey also needs when and how. Provide plain-language directions such as “follow the signs for M4”, along with expected walking time between platforms where available and the direction of the next service. Distinguish street-level entrances from platform access, and state whether a lift is required when known.

Audio output should be selective rather than continuous. A passenger might ask for the next three stops, the interchange at the next station, or a complete route to a destination. Use clear pronunciation for Turkish characters and retain the written spelling in text. Where live arrival data is available, label its update time and avoid presenting stale predictions as certain.

Connect local practice to the network

Australian readers encounter many of the same design decisions in everyday travel. In Melbourne, a Myki card is commonly touched on a tram or train; in Sydney, travellers tap an Opal or GO card; and Brisbane’s Go card works with TransLink information. Perth’s SmartRider and Transperth services add another familiar pattern. These examples show route information alongside fare habits and disruption checking.

For organisations publishing Australian services, the Disability Discrimination Act 1992 and applicable state or territory transport obligations provide the legal context for accessible public transport. The Australian Government Digital Service Standard references WCAG 2.2 AA, which is a useful technical benchmark, though legal compliance and a genuinely usable experience are different achievements. Local disability advocacy groups, accessible travel trainers and app users can reveal confusing stop names and transfer details that internal review misses.

Test, publish and maintain the map

Test the experience with people who use screen readers, including frequent travellers and first-time visitors. Check keyboard-only operation, zoom, text resizing, mobile layouts and a slow mobile connection. Offer a plain-text or accessible PDF alternative for the core route and station details, and ensure its download link has a meaningful name.

Set a clear owner and review cycle. Accessibility information changes when a lift is out of service, a station entrance closes or a line is extended. Publish those changes in the same structured data used by the map, retain dated notices when a temporary issue matters, and re-run screen-reader checks after major interface revisions.

Use automated checks to identify missing image descriptions, but verify every result against the route data and retest the complete journey. A useful release criterion is whether a passenger using a screen reader can identify their stop, the next interchange and the onward direction from the published map alone.