Het grote accessibility topic

[Mx. Alba]

Allereerst een enorme disclaimer: ik ben zelf geen webdevver! Nou ja, in de jaren '90 heb ik wel websites gebouwd, toen nog ouderwets HTML ingeklopt in een tekst-editor (vi, als je het wil weten). Begonnen met HTML 3, daarna HTML 4, XHTML 1.0, CSS en ook wat gestoeid met PHP. Daarna verloor webdevven mijn focus en tegen de tijd dat ik weer wat websites ging maken waren de online wysiwyg-tools van eenvoudige webhosts ook voldoende om mijn doelen te bereiken dus heb ik me verder niet meer in nieuwere technologieën verdiept.

Tot zover de achtergrond. Nu naar het onderwerp voor dit topic: accessibility. Sinds enige tijd heb ik een kennis die bijna volledig blind is - ze kan alleen licht waarnemen, dus ze weet of het licht of donker is, maar dat is ook alles. Door middel van screen reader software die de tekst op het scherm voorleest kan ze wel gebruik maken van een computer, maar ze gebruikt uitsluitend het toetsenbord - muishandelingen zijn bij gebrek aan zicht onmogelijk. Vrij regelmatig doet ze een beroep op mijn hulp om een niet-toegankelijke website te navigeren. Zoals net nog, wilde ze een account aanmaken op een website die, nota bene, luisterboeken aanbiedt, maar om dat te doen moest ze door een grafische captcha heen (zonder accessibility options) waar je met de muis een soort puzzeltje in elkaar moest zetten. Via Teamviewer heb ik haar computer dus moeten overnemen om dat puzzeltje voor haar te maken, zodat ze via die site luisterboeken kan lezen.

Nu leek het mij wel interessant om hier een accessiblity-vergaarbak-topic te openen, met als doel om dit vraagstuk onder de aandacht te brengen bij collega-tweakers die wel webdevven. Als het aanslaat, kunnen devvers hier vragen stellen, tips uitwisselen, en discussiëren over alles wat te maken heeft met het toegankelijk maken van websites voor mensen met een (visuele, motorische of andere) beperking. Verder heb ik helaas niet heel veel aan dit topic toe te voegen, vrees ik. Ik hoop eigenlijk dat devvers die geïnteresseerd zijn in dit onderwerp dit topic vinden en er gebruik van gaan maken, en dat andere devvers daarvan kunnen leren, om zo een steentje bij te kunnen dragen aan een toegankelijker internet.

Alvast bedankt voor de interesse!

[DJMaze]

Er zijn richtlijnen: WCAG, WAI-AA, etc.

Echter kost het ook tijd om websites compatible te maken met ARIA.
En dat geld hebben de klanten die een website laten maken niet.
En heel veel "internet bureau's" hebben niet eens mensen met kennis.
Man, man, hoe vaak ik wel geen ruzie heb gemaakt binnen bedrijven hierover

Verder kan je ook niet verwachten dat mensen die teksten op hun website zetten met plaatjes, weten hoe ze de pagina geschikt moeten maken.

[b2vjfvj75gjx7]

UA is echt een onderbelicht gebied bij veel developers, vind ik - terwijl het 1 op 1 in contact staat met het hippere SEO deel.

Zelf houd ik er altijd wel rekening mee, zodat al mijn sites minimaal met een braille-leesplankje te navigeren / gebruiken zijn en eenvoudige zaken als kleurcontrasten checken voor mensen die kleurenblind zijn (dus ik let er niet alleen op qua code, maar ook qua ontwerp).

De laatste test die ik dan doe is gewoon met een DOS browser die niets kan (afbeeldingen, scripts, css, tabellen, etc...) - als je alle content dan toch nog tot je kan nemen, weet je dat het qua UA wel goed zit...

[DJMaze]

b2vjfvj75gjx7 schreef op donderdag 5 juli 2018 @ 18:57:
eenvoudige zaken als kleurcontrasten checken voor mensen die kleurenblind zijn (dus ik let er niet alleen op qua code, maar ook qua ontwerp).

Er zijn ook heel veel mensen die 1 kleur blind zijn.

b2vjfvj75gjx7 schreef op donderdag 5 juli 2018 @ 18:57:
De laatste test die ik dan doe is gewoon met een DOS browser die niets kan (afbeeldingen, scripts, css, tabellen, etc...)

Dat is niet helemaal eerlijk, je kan namelijk aan een <img> tag een description link meegeven waarin je kan omschrijven wat er op het plaatje te zien is.
Een blinde kan dus de pagina/tekst opvragen waarop in heel veel detail wordt verteld dat het plaatje: "op de achtergrond bomen heeft met daarvoor een draaimolen met stangen waarop een kind ronddraait en daarvoor staat een vader naast een bankje een glaasje verse volle melk te drinken van Bedrijfsnaam met daaronder als slogan: 'Een glas melk is gezond voor elk'"

Dat stop je namelijk niet in het "alt" attribuut

Daarom heb ik mijn eigen CMS gebouwd met een media manager waarin je multilingual een complete omschrijving van de media (film, audio, afbeelding, etc.) kan opgeven

[ Voor 7% gewijzigd door DJMaze op 05-07-2018 19:18 ]

[b2vjfvj75gjx7]

DJMaze schreef op donderdag 5 juli 2018 @ 19:14:
[...]

Er zijn ook heel veel mensen die 1 kleur blind zijn.


[...]
Dat stop je namelijk niet in het "alt" attribuut

Klopt, ik gebruik daar de figcaption (semantisch onderdeel van de figure-tag) - daar is die ook voor bedoeld.

https://caniuse.com/#search=figcaption

En dat kan je gewoon via (bijna) elk CMS wel meegeven - al merk ik dat mijn klanten dat niet doen...

Per image-container geef ik in het CMS gewoon deze opties mee;

- alt
- title
- caption [sr only - screen reader only]
- width / height [als het een .svg file is - omdat je dit niet via mime kan achterhalen]
- seo tekst [og:img]
- filename [pretty url safe]



...en dan nog uploaden ze 5 megapixel afbeeldingen zonder context [ waar dan een smush overheen gaat ].

Het kost wat moeite om in te voeren, maar gebruikers [ en SEO ] zullen je dankbaar zijn...

[b2vjfvj75gjx7]

- edit - nieuw post (mag natuurlijk niet, maar wil het differentiëren van bovenstaande).

Wat ook veel te weinig wordt gebruikt is JSON-LD markup;

Dit is niet alleen handig voor SEO, maar vooral voor toegankelijkheid en structuur van je content (informatie overdracht van je webpagina).

Tweakers is daar bv. zeer slecht in;

https://search.google.com...k-na-afwijzing-apple.html

Ze hebben 1 entry, getagged als 'Article' terwijl het 'NewsArticle' moet zijn en de helft van de vereiste velden zijn niet aanwezig (dus een ongeldige entry voor bv. Google).

Als je de opties van bv. deze pagina ten harte neemt, zal je merken dat je niet alleen beter scoort bij zoekmachines, maar (collateral damage) ook de bruikbaarheid van je site met sprongen toeneemt;

https://developers.google...ocs/guides/search-gallery

Eenvoudige dingen als een JSON-LD breadcrumb, Search-Intention, etc... maken dat je data (content) veel beter tot zijn recht komt en je er dus ook op alternatieve wijze iets mee kan doen (niet alleen lezen via de browser, maar bv. de tekst via een API binnentrekken, etc...).

Natuurlijk, je moet een paar kb extra downloaden (bv. het artikel 2x - één keer voor de visuele weergave en één keer voor de JSON-LD 'weergave') maar hoe fijn is het dat een artikel bv. zonder tags / opmaak ook direct beschikbaar is in dezelfde pagina... dat weegt (voor mij) op tegen die paar kb extra.

[ Voor 10% gewijzigd door b2vjfvj75gjx7 op 05-07-2018 21:41 ]

[DJMaze]

Jij bent inderdaad heel goed bezig!

b2vjfvj75gjx7 schreef op donderdag 5 juli 2018 @ 21:09:
Klopt, ik gebruik daar de figcaption (semantisch onderdeel van de figure-tag) - daar is die ook voor bedoeld.
https://caniuse.com/#search=figcaption

figcaption dekt niet helemaal de lading voor een omschrijving.
Hier kan je een mooie uitleg vinden: http://www.digitalrhetori...-i-beyond-alt-attributes/

[ Voor 3% gewijzigd door DJMaze op 06-07-2018 09:45 ]

[b2vjfvj75gjx7]

DJMaze schreef op vrijdag 6 juli 2018 @ 08:50:
Jij bent inderdaad heel goed bezig!

[...]

figcaption dekt niet helemaal de lading voor een omschrijving.
Hier kan je een mooie uitleg vinden: http://www.digitalrhetori...-i-beyond-alt-attributes/

Autodidact hier, dus sommige dingen doe ik op mijn eigen logica

Maar als ik jouw voorbeeld zie, doet figcaption toch exact waar ik het voor misbruik (ik toon hem niet, maar laad hem wel in).

HTML:

 <figure class="photo">
  <img src="hank.jpg" alt="Photo of Hank the dog." />
  <figcaption class="sr-only"> /* Screen Reader only */
    Hank enjoying himself in the flower garden on a hot day.
  </figcaption>
</figure>

Voor de lurkers; als je interesse hebt in JSON-LD (structured data), zodat bv. screenreaders eenvoudiger je artikelen kunnen parsen, maar je weet niet waar te beginnen;

https://www.google.com/webmasters/markup-helper/



Dat is een eenvoudige point and click tool waarmee je de basis structuur in kaart kan brengen.

JavaScript:

<!-- JSON-LD markup generated by Google Structured Data Markup Helper. -->
<script type="application/ld+json">
{
  "@context" : "http://schema.org",
  "@type" : "Article",
  "name" : "Microsoft werkt aan donker thema voor Outlook.com",
  "author" : {
    "@type" : "Person",
    "name" : "Olaf van Miltenburg"
  },
  "datePublished" : "2018-07-06",
  "image" : "https://tweakers.net/i/ERlMeD6SzDvS3E2lEi6E01eh3SU=/fit-in/656x/filters:strip_icc()/i/2002090087.jpeg?f=imagenormal",
  "articleSection" : "Microsoft werkt al enkele maanden aan een donker thema voor Outlook.com en gaat deze op korte termijn introduceren. Het bedrijf toonde vorig jaar tijdens Halloween al een testweergave, maar die vergde nogal wat werk.",
  "articleBody" : "The best Dark Mode of any leading email client (you&#8217;ll understand when you see it, I guarantee). The sneak preview you saw last year at Halloween was a prototype that required a lot more work to be ready for prime time. (...)",
  "url" : "https://tweakers.net/nieuws/140665/virgin-orbit-krijgt-toestemming-voor-eerste-satellietlancering-met-boeing-747.html",
  "publisher" : {
    "@type" : "Organization",
    "name" : "Tweakers"
  },
  "aggregateRating" : {
    "@type" : "AggregateRating",
    "ratingValue" : "3"
  }
}
</script>

Bij Tweakers gaat er aardig wat mis, omdat ze bv. nog tags en foutieve timestamps in de artikelen zetten - maar een handmatige cleanup doet wonderen

[ Voor 53% gewijzigd door b2vjfvj75gjx7 op 06-07-2018 10:58 ]

[Merlinni]

Moet eerlijk toegeven dat bij ons (web bureau voor de MKB) ook niet altijd de focus bij UA ligt. Wij krijgen soms wel de vraag of wij een website drempel vrij (drempelvrij.nl) kunnen maken, dit is een Nederlandse kwaliteitsmerk voor toegankelijke websites.

Ik denk dat dit altijd een probleem zal blijven. Iedereen wil voor zo min mogelijk geld een website en de lokale timmerman gaat niet snel extra budget vrij maken om een site voor slechtziende etc werkend te maken.

[b2vjfvj75gjx7]

Merlinni schreef op vrijdag 6 juli 2018 @ 10:56:
Moet eerlijk toegeven dat bij ons (web bureau voor de MKB) ook niet altijd de focus bij UA heeft liggen. Wij krijgen wel de vraag of wij een website drempel vrij (drempelvrij.nl) kunnen maken, dit is een Nederlandse kwaliteitsmerk voor toegankelijke websites.

Ik denk dat dit altijd een probleem zal blijven. Iedereen wil voor zo min mogelijk geld een website en de lokale timmerman gaat niet snel extra budget vrij maken om een site voor slechtziende etc werkend te maken.

Drempelvrij is een bekende, deze tool is ook handig om snel issues in kaart te brengen;

http://wave.webaim.org/re...oor-outlook-punt-com.html

- edit - En natuurlijk hun handige extensie voor als je zelf devver bent...

http://wave.webaim.org/extension/

[ Voor 6% gewijzigd door b2vjfvj75gjx7 op 06-07-2018 11:03 ]

[DJMaze]

b2vjfvj75gjx7 schreef op vrijdag 6 juli 2018 @ 10:41:
Maar als ik jouw voorbeeld zie, doet figcaption toch exact waar ik het voor misbruik (ik toon hem niet, maar laad hem wel in).

Nope, figcaption is een visueel element. Het staat boven of onder media en geeft een korte omschrijving (net als de title attribuut).
In mijn voorbeeld link staat ook nog een <p> waar de hele gedetailleerde omschrijving van de afbeelding in staat.

Maar goed, screenreader software is hopeloos.
Ook al doe je je stinkende best om alles goed te hebben, die krengen werken gewoon niet: https://www.powermapper.c...ing/img-aria-describedby/

[ Voor 18% gewijzigd door DJMaze op 06-07-2018 11:38 ]

[b2vjfvj75gjx7]

DJMaze schreef op vrijdag 6 juli 2018 @ 11:29:
[...]

Nope, figcaption is een visueel element. Het staat boven of onder media en geeft een korte omschrijving (net als de title attribuut).
In mijn voorbeeld link staat ook nog een <p> waar de hele gedetailleerde omschrijving van de afbeelding in staat.

Maar goed, screenreader software is hopeloos.
Ook al doe je je stinkende best om alles goed te hebben, die krengen werken gewoon niet: https://www.powermapper.c...ing/img-aria-describedby/

Interessante link - daar gaat inderdaad een boel mis.

Overigens test ik zelf ook niet alles met fysieke readers - maar heb wel een 'test straat' waar ik alle pagina's door heen haal (CSS uit, JS uit, DOS browser, een paar online checks, etc...).

Als de content dan 'gewoon' leesbaar en bereikbaar is - en je ook nog een stapel semantiek weet te ontfutselen, dan ben ik tevreden.

En inderdaad; feitelijk kost het 2x zo veel tijd - eerst ga je de site optimaliseren voor visueel gebruik (design, responsive, etc...) en dan nog een keer voor gebruikers zonder visuele zintuigen... niet elke opdrachtgever wil dat (gelukkig werk ik zelfstandig en besteed er graag wat uren / avonden gratis aan, voordat ik de site oplever).

[DJMaze]

b2vjfvj75gjx7 schreef op vrijdag 6 juli 2018 @ 11:53:
niet elke opdrachtgever wil dat (gelukkig werk ik zelfstandig en besteed er graag wat uren / avonden gratis aan, voordat ik de site oplever).

Idem hier, maar ik trek wel een grens.
Bij een korfbalvereniging doe ik dat bijvoorbeeld niet, als je begrijpt wat ik bedoel.

[Mx. Alba]

De site van een korfbalvereniging hoeft natuurlijk ook niet per se toegankelijk te zijn omdat de kans dat mensen met een beperking daarin geïnteresseerd zijn heel erg klein is. Toch zou het natuurlijk beter zijn als de site wel toegankelijk is - maar als je dan toch moeite moet doen, is het beter om dat te doen voor sites die er wel toe doen.

@b2vjfvj75gjx7 is het niet vreemd om bijvoorbeeld gratis de site van een retailer toegankelijk te maken omdat zij er zelf niet voor willen betalen, wat hun dan vervolgens klanten met een beperking oplevert omdat zij zo prettig met die site kunnen werken? Het is een interessant dilemma...

[DJMaze]

@Mx. Alba hangt van de retailer af, denk je niet?
Een ondernemer krijgt van mij een webshop systeem die het ingebakken heeft. Moet hij wel zelf de teksten goed vullen en hoeft hij mij niet te betalen.

Een startende ondernemer krijgt van mij wel gratis uitleg als hij "ja" antwoord op mijn vraag "wil je ook verkopen aan visueel beperkte mensen?".

De lokale buurtvereniging krijgt het van mij.

[crisp]

b2vjfvj75gjx7 schreef op donderdag 5 juli 2018 @ 21:28:
- edit - nieuw post (mag natuurlijk niet, maar wil het differentiëren van bovenstaande).

Tweakers is daar bv. zeer slecht in;
[...]

offtopic:
Binnenkort komt er een release waar we ook JSON-LD geimplementeerd hebben. Feit is eigenlijk dat JSON-LD al zo'n beetje de '3e generatie' meta-markup is (na microdata/microformats en RDFa) en dat implementaties de neiging hebben in de loop der tijd af te takelen omdat het zo weinig zichtbaar is en er niet altijd op getest wordt of rekening mee wordt gehouden bij wijzigingen in code of structuur...

[ Voor 5% gewijzigd door crisp op 06-07-2018 13:52 ]

[DJMaze]

crisp schreef op vrijdag 6 juli 2018 @ 13:51:

offtopic:
Feit is eigenlijk dat JSON-LD al zo'n beetje de '3e generatie' meta-markup is (na microdata/microformats en RDFa)

[b2vjfvj75gjx7]

Mx. Alba schreef op vrijdag 6 juli 2018 @ 13:29:


@b2vjfvj75gjx7 is het niet vreemd om bijvoorbeeld gratis de site van een retailer toegankelijk te maken omdat zij er zelf niet voor willen betalen, wat hun dan vervolgens klanten met een beperking oplevert omdat zij zo prettig met die site kunnen werken? Het is een interessant dilemma...

Tja, het heeft ook met 'eergevoel' te maken dat je niet iets oplevert dat aantoonbaar slecht is.

Overigens werk ik als ZZP devver (front- en back-end) voor middelgrote en iets grotere toko's - die hebben wel budget voor development meestal.

Maar als ik vooraf een urenspecificatie indien en ze zien daar '24 uur UA optimalisatie' dan sneuvelt dat direct... tegelijkertijd; als je goed ontwikkelt, moet je wel heel slecht ontwikkelen om een site totaal ontoegankelijk te maken

Dus als je in de basis 'een beetje' rekening houdt met toegankelijkheid / screenreaders / kleurblinden / etc... dan heb je wel een solide basis voor je framework, en dan zijn het relatief kleine aanpassingen om het nét iets beter te maken (arials, labels, etc... plaatsen).

Los daarvan ben ik ook gewoon beroeps-deformist; ik blijf net zo lang op W3C Validation rammen tot ik 100% scoor - ook al weet ik dat die ene % op het eind net zo goed genegeerd kan worden...

crisp schreef op vrijdag 6 juli 2018 @ 13:51:
[...]

offtopic:
Binnenkort komt er een release waar we ook JSON-LD geimplementeerd hebben. Feit is eigenlijk dat JSON-LD al zo'n beetje de '3e generatie' meta-markup is (na microdata/microformats en RDFa) en dat implementaties de neiging hebben in de loop der tijd af te takelen omdat het zo weinig zichtbaar is en er niet altijd op getest wordt of rekening mee wordt gehouden bij wijzigingen in code of structuur...

Klopt allemaal - bedankt voor je antwoord.

Overigens heb ik gemerkt dat JSON-LD en Microdata hetzelfde worden gewaardeerd (technisch) door Google.

Als test heb ik diverse pagina's gemaakt met exact dezelfde content in Microdata Format en daarnaast JSON-LD -> exact dezelfde test / meetresultaten.

Als je dan een pagina met bestaande Microdata pakt en daar JSON-LD aan toe voegt (met de data uit de Microdata), dan ziet Google het gewoon als doublure; dus beide invoeren heeft weinig nut.

Voordeel van JSON vind ik dat het wel een redelijk stabiele standaard is, en de meeste talen er een native parser voor hebben (PHP / JS in mijn geval) - dus die data lees je zo uit.

En het leuke vind ik zelf weer dat je bijna direct resultaat in Google ziet... bv. hoe je pagina van breadcrumbs wordt voorzien in de zoekresultaten, maar ook zo iets als een Aggregated Rating per pagina die middels een ster-systeem live aangestuurd kan worden;

Heb je opeens vindresultaten met sterren er onder en reken maar dat dat beter scoort dan dezelfde verwijzing zonder sterren.

Mijn meeste sites maak ik gewoon in WordPress (ja ja, vloeken...) maar wel hoe het hoort;

WordPress als CMS en de hele blueprint / template / router functies in native PHP.

Via ACF trek ik dan alle toegankelijkheidsdata gewoon uit de back-end en plaats die in Microdata / JSON opmaak...

...grootste issue is en blijft dat klanten persé een CMS willen en vervolgens de data niet goed, of onvolledig invoeren... kan je nog zo'n mooi systeem aanleveren, de bottleneck blijft de content

[ Voor 24% gewijzigd door b2vjfvj75gjx7 op 06-07-2018 17:02 ]

[crisp]

@b2vjfvj75gjx7 het voordeel van JSON-LD boven microdata is dat je de data kan consolideren en het niet meer verweven is met de markup. Dat maakt het hopelijk wat robuuster in complexe en veranderlijke codebases zoals de onze

[DJMaze]

@b2vjfvj75gjx7 ik gebruik geen WordPress, ik gebruik mijn eigen CMS.
Lekker rustig, geen GDPR/hack issues maar voornamelijk omdat de WYSIWYG een soort XML variant is.
Alles template/content data gaat door een XML parser, dus zelfs de klant is met zijn teksten 100% W3C-Validated

[b2vjfvj75gjx7]

DJMaze schreef op vrijdag 6 juli 2018 @ 18:02:
@b2vjfvj75gjx7 ik gebruik geen WordPress, ik gebruik mijn eigen CMS.
Lekker rustig, geen GDPR/hack issues maar voornamelijk omdat de WYSIWYG een soort XML variant is.
Alles template/content data gaat door een XML parser, dus zelfs de klant is met zijn teksten 100% W3C-Validated

In WordPress werkt ik veel met YAML syntax voor content (-validatie).

Maar na jaren echt keihard pushen van die techniek naar klanten toe, ben ik er maar mee gestopt (om het actief te promoten).

Ze willen nu eenmaal WordPress, en dan het liefst de brakke editor ipv. markdown... ook wel logisch, vanuit UA / UI / UE (wat een termen ook... user accessibility, user interface, user experience) gezien.

De meest gebruikte oplossing is (ook bij WordPress) zeker niet de beste... hooguit de meest gebruikte.

[b2vjfvj75gjx7]

crisp schreef op vrijdag 6 juli 2018 @ 17:42:
@b2vjfvj75gjx7 het voordeel van JSON-LD boven microdata is dat je de data kan consolideren en het niet meer verweven is met de markup. Dat maakt het hopelijk wat robuuster in complexe en veranderlijke codebases zoals de onze

Klopt, het is vaak ook een pain in the ass om data (die je wel zichtbaar wil hebben) van de juiste classes / scopes te voorzien en de boel toch leesbaar te houden (zowel voor de eindgebruiker als op broncode niveau).

Soms zit je echt quirks uit te halen waarbij je denkt... WTF!

Nadeel van JSON is weer dubbele data; eerst plaats je de Articlebody gewoon in de <article> tag (voor de browser, zeg maar) en dan nog een keer die hele sloot aan tekst (strip_tags...) in de JSON-container...

...het is maar een paar kb extra, maar echt optimaal is het ook niet (al doe ik het trouw; alles voor de bereikbaarheid van de content!).

[JJ93]

De afgelopen vijf maanden heb ik onderzoek gedaan naar smartphone toegankelijkheid voor blinden en slechtzienden. Met deze inzichten heb ik een app voor iOS en Android ontwikkeld, volledig toegankelijk met VoiceOver en Talkback. Deze maand ben ik bezig om alle resultaten te verwerken.

Wat mij misschien nog wel het meest opviel is dat screen readers niet goed omgaan met inhoud uit een andere taal. Bijvoorbeeld: iPhone in het Nederlands ingesteld en een app die alleen beschikbaar in het Engels. Dan wordt met een Nederlands 'accent' alles voorgelezen, brak Engels dus en amper te volgen. Net al een TomTom die Franse plaatsnamen uitspreekt in het Nederlands.

Een ander probleem zijn interface wijzigingen die vaak niet of slecht worden gecommuniceerd. Zelfs met apps die (voornamelijk) gericht zijn op mensen met een visuele beperking. En bij grote bedrijven gaat het ook vaak fout, bij Facebook bijvoorbeeld. Laatst kon VoiceOver berichten met de 'awesome background' bijvoorbeeld niet mee voorlezen.

Zeker voor personen die volledig blind zijn is het bij elke update weer een kwestie van uitproberen om er achter te komen wat er veranderd is. Het zoeken naar bepaalde knoppen of functies. Dingen niet meer kunnen. Net als met een feature changelog zou het handig zijn om ook een design changelog te hebben.

Hetzelfde geldt voor websites, er worden vaak veranderingen gepusht zonder enige mededeling.

Voor de web developers: wat raden jullie mij aan voor een toegankelijke website met webshop in meerdere talen? Zelf zat ik te denken aan Wordpress + WooCommerce.

[Mx. Alba]

JJ93 schreef op maandag 9 juli 2018 @ 15:33:
Zeker voor personen die volledig blind zijn is het bij elke update weer een kwestie van uitproberen om er achter te komen wat er veranderd is. Het zoeken naar bepaalde knoppen of functies. Dingen niet meer kunnen. Net als met een feature changelog zou het handig zijn om ook een design changelog te hebben.

Daar kwam ik dus ook achter toen die vriendin me vroeg om haar te helpen met haar antivirus. Het blijkt dat geen enkel antivirusprogramma correct werkt met screen readers. Ze hebben allemaal zo'n mooie gelikte moderne interface maar daardoor zijn ze bijna onbruikbaar voor blinden. De enige die een beetje bruikbaar blijkt is Kaspersky - maar de installer daarvan is compleet ontoegankelijk. Kennelijk was Avast enkele versies geleden wel goed toegankelijk maar opeens met een nieuwe update ging dat bijna volledig de prullenbak in en zit je als blinde als het ware tegen een groot zwart vlak aan te staren...

[JJ93]

Bij Facebook gaat het ook regelmatig fout, terwijl ze miljoenen gebruikers hebben die gebruik maken van VoiceOver. Zie: https://www.facebook.com/accessibility/

Wat het ook lastig maakt is het gebruiken van componenten van anderen. Al is een component nog zo populair, soms is het voor VoiceOver of Talkback gebruikers niet te gebruiken.

VoiceOver aanzetten iOS 11: Instellingen > Algemeen > Toegankelijkheid > VoiceOver > Aan
TalkBack aanzetten Android 7: Instellingen > Toegankelijkheid > Talkback > Aan

Bij veel websites is het al zo dat er meer mobiele bezoekers zijn dan desktop bezoekers. Dus ik zou zeggen: zet eens VoiceOver of Talkback aan en check of je website nog te gebruiken is!

[R4gnax]

JJ93 schreef op maandag 9 juli 2018 @ 15:33:
Wat mij misschien nog wel het meest opviel is dat screen readers niet goed omgaan met inhoud uit een andere taal. Bijvoorbeeld: iPhone in het Nederlands ingesteld en een app die alleen beschikbaar in het Engels. Dan wordt met een Nederlands 'accent' alles voorgelezen, brak Engels dus en amper te volgen. Net al een TomTom die Franse plaatsnamen uitspreekt in het Nederlands.

Is dat de fout van de screen-reader software, of van de app die niet goed doorgeeft wat de taal van oorsprong van de content is?

Als je bijv. naar web-based content kijkt, hoort een auteur via markers zoals het lang attribuut te kunnen sturen in de gebruikte taal, en daar luistert screen-reader software in het algemeen ook naar.

Zie bijv. https://developer.paciell...-the-html-lang-attribute/

[JJ93]

R4gnax schreef op maandag 23 juli 2018 @ 21:45:
[...]


Is dat de fout van de screen-reader software, of van de app die niet goed doorgeeft wat de taal van oorsprong van de content is?

Als je bijv. naar web-based content kijkt, hoort een auteur via markers zoals het lang attribuut te kunnen sturen in de gebruikte taal, en daar luistert screen-reader software in het algemeen ook naar.

Zie bijv. https://developer.paciell...-the-html-lang-attribute/

Het switchen tussen talen gaat bij Safari inderdaad wel goed.
Waarom het bij apps niet goed gaat is voor mij nog steeds onduidelijk. Want je kan wel de taal van de content aangeven.

[draak42]

Goed topic dit

Ik ben zelf blind en dus screenreader gebruiker op zowel mobile als desktop en heb alle besturingssystemen met bijbehorende screen readers wel in handen gehad. Veel van de dingen die jullie noemen zijn helaas maar al te bekend. Wat het wisselen van taal betreft gaat dit in veel gevallen inderdaad goed op websites, maar in apps is dit een drama. Het is zo erg dat ik (en met mij vele anderen) er aan gewend zijn geraakt engelse tekst door een nederlandse stem te laten voorlezen, maar fijn is anders.

Mocht iemand vragen hebben of mogelijk zijn app / website wil laten testen op accessibility door een eindgebruiker, stuur me gerust een berichtje. Ik studeer business IT management en ben volledig blind, dus voor een aantal bedrijfjes ben ik al een prima testpersoon gebleken

In ieder geval mooi dat dit topic er is, en bij vragen, stel ze gerust:)