Toegankelijkheid

Dit gedeelte is de reden waarom deze pagina de moeite van het publiceren waard is. Elk punt is echt, we weten ervan en geen ervan wordt hier als opgelost gepresenteerd.

De site is in dertig talen gepubliceerd en is niet in al die talen getest met een schermlezer. Er is getest in het Engels. Uitspraak en leesvolgorde in talen die van rechts naar links worden geschreven, en in schriften waarvoor onze displaylettertypen geen dekking hebben en het platformlettertype wordt gebruikt, zijn niet geverifieerd met hulptechnologie.

Onze twee lettertypen ondersteunen alleen het Latijnse schrift. Cyrillisch, Devanagari, Georgisch, Thai, Arabisch, Hebreeuws, Bengaals, Ethiopisch en CJK vallen allemaal terug op de eigen lettertypen van het platform. Dat is over het algemeen goed voor de leesbaarheid, maar het betekent ook dat de typografische details die we in het Engels beheersen — gewicht, spatiëring en de grootte waarbij kleine tekst niet langer klein genoeg is — in die lokale versies niet door ons worden beheerst.

Sommige interactieve elementen zijn nieuw en minder uitgebreid getest. De vergelijkingsmatrix en de zoekfunctie van de helpsectie filteren rijen op hun plaats, wat het juiste patroon is, maar het aankondigen van een gewijzigd aantal resultaten aan een schermlezer is wel geïmplementeerd en nog niet door gebruikers getest.

Voor de app geldt dezelfde intentie, maar deze wordt minder vaak gecontroleerd dan de site. De app ondersteunt de eigen functies van het platform voor tekstgrootte en schermlezers, die het meeste werk doen, maar momenteel voeren we niet bij elke release een formele toegankelijkheidsaudit uit.

Er is geen formele audit door een externe partij uitgevoerd voor de site of de app. We zeggen dat liever eerlijk dan dat we een certificering suggereren die we niet hebben.

De Telvio-app maakt gebruik van de toegankelijkheidsfuncties van het besturingssysteem waarop deze draait: VoiceOver en Dynamic Type op iOS, TalkBack en schalen van lettertypen op Android. Die dekken het grootste deel van wat belangrijk is in een app waarvan de interface bestaat uit een toetsenblok, een saldo en een lijst met tarieven.

Eén ontwerpbeslissing verdient aandacht als toegankelijkheidseigenschap in plaats van als functie. Omdat de app geen account vereist, is er geen registratieformulier, geen wachtwoord om in te voeren, geen e-mailverificatiestap en geen code om uit een bericht te halen — de hele categorie interacties die mensen met hulptechnologie, of iedereen die formulieren lastig vindt, het vaakst in de problemen brengt, is eenvoudigweg niet aanwezig. Installeren, bellen, praten.

De bijbehorende beperking staat op dezelfde pagina als al het andere: met de app kun je geen noodhulpdiensten bellen. Dat staat uitgelegd bij noodoproepen. Als iemand deze app instelt voor een familielid — een veelvoorkomend patroon, vooral bij oudere mensen die familie in het buitenland bellen — is dat het belangrijkste om tijdens het instellen uit te leggen.

E-mail [email protected] met als onderwerp Accessibility. Nuttige details zijn: de pagina of het scherm, wat je probeerde te doen, welke hulptechnologie je gebruikte inclusief de versie ervan, en wat er in plaats daarvan gebeurde. Niets daarvan is verplicht — een zin als “Ik kan de tabel met tarieven niet gebruiken met een schermlezer” is een prima melding en die ontvangen we liever dan helemaal niets.

We streven ernaar binnen vijf werkdagen te antwoorden met een beoordeling en, als we het ermee eens zijn dat er een defect is, een globale planning. Dingen die iemand verhinderen een taak af te ronden, krijgen voorrang op ander werk; dingen die een taak moeilijker maken, worden eerlijk ingepland in plaats van vaag beloofd.

Als je in de Europese Unie bent en denkt dat er niet aan een toegankelijkheidsverplichting wordt voldaan, kun je dit ook melden bij de bevoegde nationale handhavingsinstantie. We hebben liever dat je eerst bij ons aanklopt en zullen hoe dan ook antwoorden.

Twee dingen verdienen uitleg, omdat ze het verschil maken tussen een verklaring en een werkwijze.

Contrast wordt weergegeven, niet uitgelezen. Een kleurwaarde die uit een stylesheet wordt gehaald, vertelt je wat een element moest zijn, niet hoe het er uiteindelijk uitzag — bijvoorbeeld een semi-transparant element over een donkere band, een moderne kleurfunctie die een regex niet begrijpt, of een vaste header over een hero-afbeelding. De controle rendert de echte achtergrond van elk element door omhoog te lopen naar de eerste ondoorzichtige voorouder en de kleur via de browser zelf vast te stellen, waarna de verhouding wordt berekend. Zo werd ontdekt dat de hoofdtekst op deze site een verhouding van 4.49:1 had, onder AA, hoewel die er op zichzelf volkomen normaal uitziet.

De pagina wordt gecontroleerd zoals die wordt weergegeven, niet zoals die is geschreven. Een afzonderlijke probe laadt elke pagina in een echte browser en controleert of tekst in de viewport een opacity van nul heeft, of het document horizontaal scrollt en of iets wordt weergegeven in zijn eigen achtergrondkleur. Dat laatste klinkt absurd tot het in productie komt: een enkele gegroepeerde CSS-regel stelde ooit de kleur en achtergrond van een label in op dezelfde waarde, wat een contrastverhouding van 1:1 opleverde die onzichtbaar is in de markup, onzichtbaar in de DOM en onzichtbaar in een screenshot van de bron.