tweakers toegankelijkheid voor blinden en slechtzienden

[draak42]

Beste tweakers,

Ik gebruik tweakers.net en het forum met veel plezier, maar loop hierbij wel tegen een aantal bugs aan. Dit komt doordat ik tweakers gebruik met een screenreader omdat ik blind ben. Op mijn windows laptop is dit nvda (www.nvaccess.org) en op mijn iPhone is dat voiceover (ingebouwd in iOs. Hierbij bedien ik mijn laptop en iPhone volledig nonvisueel, dus zonder naar het scherm te kijken en zonder gebruik van de muis. Daardoor zijn een aantal functies van tweakers.net slecht of niet bruikbaar. Hieronder de voor mij meest belangrijke problemen.
1: Op het forum is het lastig om naar de notificaties en priveberichten te komen, omdat deze in een soort popup geopend lijken te worden. De focus beland daar niet automatisch, en er is een gesimuleerde muisklik nodig om deze actie te trigeren. Dat is zowel op mobiel als op laptop erg lastig zonder muis te doen. Is het mogelijk deze vensters ook met het toetsenbord te openen?
2: In de price watch is het mogelijk om filters in te stellen. Dit moet door middel van slepen. Dit is op mobiel heel lastig, en op de laptop zelfs onmogelijk te doen zonder de muis. Is het mogelijk de waarden van je filter ook op een andere manier (zonder muis) in te kunnen geven?
3: bij het geven van moderaties op de frontpage moet je een soort popup openen, ik heb nog geen manier gevonden om dit zonder muis voor elkaar te krijgen.

Dit zijn voor mij nu de meest aanwezige bugs. Ik heb hierbij niet alle functies van tweakers volledig gebruikt en getest, dus het is goed mogelijk dat ik een en ander heb gemist.
Zou hiernaar gekeken kunnen worden door de developers van de site? Dit zou tweakers voor mensen met een visuele beperking of mensen die om een andere reden geen muis kunnen gebruiken een stuk bruikbaarder maken.

[crisp]

Aangezien dit niet zozeer bugs zijn en de mate van ondersteuning van alternatieve invoermethoden in feite een keuze van het productteam is verplaats ik deze even naar Mooie Features

[draak42]

crisp schreef op zaterdag 28 juli 2018 @ 20:29:
Aangezien dit niet zozeer bugs zijn en de mate van ondersteuning van alternatieve invoermethoden in feite een keuze van het productteam is verplaats ik deze even naar Mooie Features

Ok, begrijpelijk. Ik twijfelde al waar dit het beste thuis hoorde, omdat het voor mij aanvoelt als bugs, maar dit natuurlijk voor een groot deel van de community die wel met een muis kunnen werken niet zo is.

[Ossi]

Lijkt mij netjes om te implementeren voor de slechtzienden en blinden. Misschien dat @draak42 voor jullie af en toe wat testwerkzaamheden kan verrichten voor bijvoorbeeld nieuwe features.

[draak42]

Ossi schreef op dinsdag 31 juli 2018 @ 18:49:
Lijkt mij netjes om te implementeren voor de slechtzienden en blinden. Misschien dat @draak42 voor jullie af en toe wat testwerkzaamheden kan verrichten voor bijvoorbeeld nieuwe features.

Dit is voor mij zeker een mogelijkheid, dat doe ik graag. En ik ken een groot aantal andere blinde / slechtziende mensen die graag de tweakers site meer zouden willen gebruiken en zeker bereid zullen zijn daar hun steentje aan bij te dragen dmv testen een feedback geven. Ik hoop dat er een mogelijkheid is voor de devs om dit op te pakken, omdat het de website voor mij en vele anderen een stuk bruikbaarder zou maken.

[ACM]

draak42 schreef op dinsdag 31 juli 2018 @ 20:39:
Ik hoop dat er een mogelijkheid is voor de devs om dit op te pakken, omdat het de website voor mij en vele anderen een stuk bruikbaarder zou maken.

Het is natuurlijk sowieso wel een wens om ook de bezoekers met beperkingen, naast zicht bijvoorbeeld ook motorisch, te helpen. Maar het vervelende is dat de gebruiksvriendelijkheid verbeteren voor de groep die dat niet heeft, vaak zorgt voor meer fancy dingen die zelfs door browsermakers lang niet altijd even doordacht zijn uitgewerkt voor diegenen die er moeite mee hebben. En dat wij zelf dergelijke beperkingen niet ervaren maakt het helaas erg lastig om er continu aan te denken of een goede voorstelling te maken van wat er dan anders moet.

Wat dat betreft zijn accessibility en usability helaas lang niet altijd synoniem en als je de extremen opzoekt zelfs tegengesteld.

Daardoor durf ik geen beloftes te doen dat het daadwerkelijk gaat lukken, maar ik zal onze UX-expert zometeen ook weer even op dit fenomeen wijzen. Er zijn wat aankomende plannen die toevallig raakvlak hebben met een paar van je benoemde problemen, dus wellicht dat er wat aanpassingen meegenomen kunnen worden die hierbij helpen.

Voor jouw concrete problemen heb ik een paar ideeen die je misschien nu al kunnen helpen:

Voor de notificaties en de priveberichten zijn directe links beschikbaar, de popupjes heb je in theorie niet nodig: notificaties en priveberichten.
Je krijgt dan natuurlijk wel alle recente berichten en notificaties, maar ik leid uit je reactie af dat je wel duidelijk is dat er nieuwe notificaties of berichten zijn, dus wellicht helpt dit

Voor de filters in de pricewatch is ironisch genoeg het feit dat browsers voor blinden steeds beter met javascript omgaan juist een beetje een probleem.
Is het voor jou makkelijk om voor specifieke pagina's de javascript uit te zetten? In dat geval krijg je namelijk reguliere formulieren voor het opgeven van je filters. Echt heel gebruiksvriendelijk zal het niet zijn, omdat er vaak heel veel keuze opties zijn, maar misschien werkt het beter voor je.

Voor het geven van moderaties heb ik helaas zo gauw geen oplossing.

[draak42]

ACM schreef op woensdag 1 augustus 2018 @ 08:49:
[...]

Het is natuurlijk sowieso wel een wens om ook de bezoekers met beperkingen, naast zicht bijvoorbeeld ook motorisch, te helpen. Maar het vervelende is dat de gebruiksvriendelijkheid verbeteren voor de groep die dat niet heeft, vaak zorgt voor meer fancy dingen die zelfs door browsermakers lang niet altijd even doordacht zijn uitgewerkt voor diegenen die er moeite mee hebben. En dat wij zelf dergelijke beperkingen niet ervaren maakt het helaas erg lastig om er continu aan te denken of een goede voorstelling te maken van wat er dan anders moet.

Wat dat betreft zijn accessibility en usability helaas lang niet altijd synoniem en als je de extremen opzoekt zelfs tegengesteld.

Daardoor durf ik geen beloftes te doen dat het daadwerkelijk gaat lukken, maar ik zal onze UX-expert zometeen ook weer even op dit fenomeen wijzen. Er zijn wat aankomende plannen die toevallig raakvlak hebben met een paar van je benoemde problemen, dus wellicht dat er wat aanpassingen meegenomen kunnen worden die hierbij helpen.

Voor jouw concrete problemen heb ik een paar ideeen die je misschien nu al kunnen helpen:

Voor de notificaties en de priveberichten zijn directe links beschikbaar, de popupjes heb je in theorie niet nodig: notificaties en priveberichten.
Je krijgt dan natuurlijk wel alle recente berichten en notificaties, maar ik leid uit je reactie af dat je wel duidelijk is dat er nieuwe notificaties of berichten zijn, dus wellicht helpt dit

Voor de filters in de pricewatch is ironisch genoeg het feit dat browsers voor blinden steeds beter met javascript omgaan juist een beetje een probleem.
Is het voor jou makkelijk om voor specifieke pagina's de javascript uit te zetten? In dat geval krijg je namelijk reguliere formulieren voor het opgeven van je filters. Echt heel gebruiksvriendelijk zal het niet zijn, omdat er vaak heel veel keuze opties zijn, maar misschien werkt het beter voor je.

Voor het geven van moderaties heb ik helaas zo gauw geen oplossing.

Dank voor je reactie, tof dat dit binnen tweakers word opgepakt. Fijn dat er ook direct meegedacht word over manieren om de site voor mij beter bruikbaar te maken, daar heb ik zeker wat aan. Ik ben benieuwd of het mogelijk hier in het design van de site wat aan te doen, maar inderdaad geeft usability en accessibility soms conflicten. Misschien zou dit opgelost kunnen worden door een instelling in je tweakers account die ervoor zorgt dat je zodra je ingelogd bent een toegankelijkere site krijgt. En als er onderdelen van de site getest moeten worden op accessibility, vraag gerust:)

[ACM]

draak42 schreef op woensdag 1 augustus 2018 @ 20:46:
Ik ben benieuwd of het mogelijk hier in het design van de site wat aan te doen, maar inderdaad geeft usability en accessibility soms conflicten.

Dat hopen we ook. Er is een bijkomende use case die ook muisgebruik moeizaam maakt, namelijk de hele mobiele wereld. Daarop is het ook lastig om de sliders bij de filters goed in te stellen, dus daar zijn we sowieso al naar aan het kijken. Hopelijk denken we tegen de tijd dat we dat gaan maken nog aan je

Misschien zou dit opgelost kunnen worden door een instelling in je tweakers account die ervoor zorgt dat je zodra je ingelogd bent een toegankelijkere site krijgt.

Een instelling is iets wat we eigenlijk liever niet doen, simpelweg omdat er dan een grote groep het nooit ontdekt en dus niet zal gebruiken en we toch met het dubbele onderhoud zitten. Dan hebben we het liever zo geintegreerd dat je steeds zichtbaar kan switchen op plekken waar het relevant is.

En als er onderdelen van de site getest moeten worden op accessibility, vraag gerust:)

Ook dat heb ik bij onze UX-expert benadrukt, dat je graag helpt met testen

[gekkie]

Misschien uiteindelijk nog wel wat voor een artikel, web UI en "usability en accessibility", met tweakers zelf als case. Er zullen immers legio sites zijn die op dit vlak (eenvoudig) verbeterd zouden kunnen worden.

Juist omdat het voor de gemiddelde designer / programmeur lastig is omdat:

• deze zelf geen beperking heeft en dus ook nooit de site met hulpmiddelen bezoekt
• in combinatie met het voorgaande er nog wel eens gekozen zal worden voor meer eyecandy ipv "usability en accessibility"

Kortom zou best interessant kunnen zijn om in een artikel eens te zien wat er aan hulpmiddelen zijn, hoe deze interacteren met de elementen van een website; en misschien wel het belangrijkste, welk relatief laaghangend fruit er is waarmee je toch al aardig wat verbeteringen kunt bewerkstelligen.

[Silver7]

Nou, ik meld hier maar ook even:

Zouden jullie bij video's ook ondertiteling kunnen regelen?

[ACM]

Silver7 schreef op donderdag 2 augustus 2018 @ 09:42:
Nou, ik meld hier maar ook even:

Zouden jullie bij video's ook ondertiteling kunnen regelen?

Of dat nu al technisch mogelijk zou zijn weet ik eigenlijk niet, maar we zijn al bezig met een migratie naar YouTube. En zij ondersteunen sowieso ondertitels.

Dus in mijn ogen is dat puur een organisatorisch iets wat niet meer onder een feature request

En ik heb liever dit topic dan concreet voor dingen waar we daadwerkelijk de techniek voor zouden moeten veranderen.

[ Voor 3% gewijzigd door ACM op 02-08-2018 12:00 ]

[Mx. Alba]

Wellicht interessant: op ons webdev-subforum heb ik een tijdje geleden dit topic geopend: Het grote accessibility topic

Ik kwam op het idee om dat topic te openen omdat ik regelmatig een blinde vriendin help om niet-toegankelijke sites of programma's te navigeren. Waar ik bijvoorbeeld achter kwam is dat er geen enkel antivirusprogramma is dat volledig toegankelijk is voor blinden en slechtzienden... Maar bijvoorbeeld ook dat een website die nota bene luisterboeken aanbiedt een grafische captcha gebruikt om de registratie te beveiligen. Van dat soort dingen, daar gaan je oren echt van klapperen.

En inderdaad, mensen zonder een dergelijke beperking denken daar vaak helemaal niet over na, dus op zich is het niet zo vreemd dat veel sites en software niet (voldoende) toegankelijk zijn... Maar het is wel heel jammer. En het zou beter kunnen, en beter moeten.

[draak42]

Mx. Alba schreef op donderdag 2 augustus 2018 @ 12:21:
Wellicht interessant: op ons webdev-subforum heb ik een tijdje geleden dit topic geopend: Het grote accessibility topic

Ik kwam op het idee om dat topic te openen omdat ik regelmatig een blinde vriendin help om niet-toegankelijke sites of programma's te navigeren. Waar ik bijvoorbeeld achter kwam is dat er geen enkel antivirusprogramma is dat volledig toegankelijk is voor blinden en slechtzienden... Maar bijvoorbeeld ook dat een website die nota bene luisterboeken aanbiedt een grafische captcha gebruikt om de registratie te beveiligen. Van dat soort dingen, daar gaan je oren echt van klapperen.

En inderdaad, mensen zonder een dergelijke beperking denken daar vaak helemaal niet over na, dus op zich is het niet zo vreemd dat veel sites en software niet (voldoende) toegankelijk zijn... Maar het is wel heel jammer. En het zou beter kunnen, en beter moeten.

Tof toppic, en inderdaad erg herkenbaar wat je schrijft. Het komt vaak voor dat hele normale computertaken niet mogelijk zijn of via een enorme omweg moeten. Ik studeer zelf in de richting van ict en ben meestal goed in staat de beperkingen van de toegankelijkheid te omzeilen, maar dat is zeker voor minder ervaren computergebruikers erg lastig. Mooi om in ieder geval te zien dat dit leeft binnen de community van tweakers, ik zal ook in je gelinkte topic even reageren.

[Karp]

crisp schreef op zaterdag 28 juli 2018 @ 20:29:
Aangezien dit niet zozeer bugs zijn en de mate van ondersteuning van alternatieve invoermethoden in feite een keuze van het productteam is verplaats ik deze even naar Mooie Features

Accessibility issues zijn wel degelijk bugs. Je bent een deel van je gebruikers aan het buitensluiten wat in feite gewoon discriminatie is.
Daarnaast wordt er eigenlijk gewoon incorrecte HTML gebruikt voor bijvoorbeeld de notificaties en priveberichten. Dat zouden buttons moeten zijn. De hele rechterbovensectie is nu niet te bedienen met het toetsenbord. Ga maar eens met je tab-toets door een paar pagina's van tweakers heen, en kijk eens hoeveel interactieve elementen je niet kan bereiken. Dat is echt zonde en zou niet hoeven.

ACM schreef op woensdag 1 augustus 2018 @ 08:49:
[...]

Het is natuurlijk sowieso wel een wens om ook de bezoekers met beperkingen, naast zicht bijvoorbeeld ook motorisch, te helpen. Maar het vervelende is dat de gebruiksvriendelijkheid verbeteren voor de groep die dat niet heeft, vaak zorgt voor meer fancy dingen die zelfs door browsermakers lang niet altijd even doordacht zijn uitgewerkt voor diegenen die er moeite mee hebben. En dat wij zelf dergelijke beperkingen niet ervaren maakt het helaas erg lastig om er continu aan te denken of een goede voorstelling te maken van wat er dan anders moet.

Wat dat betreft zijn accessibility en usability helaas lang niet altijd synoniem en als je de extremen opzoekt zelfs tegengesteld.

Daardoor durf ik geen beloftes te doen dat het daadwerkelijk gaat lukken, maar ik zal onze UX-expert zometeen ook weer even op dit fenomeen wijzen. Er zijn wat aankomende plannen die toevallig raakvlak hebben met een paar van je benoemde problemen, dus wellicht dat er wat aanpassingen meegenomen kunnen worden die hierbij helpen.

Ik ben heel benieuwd wat voor voorbeelden je kan noemen waar accessibility en usability tegenovergesteld zijn. In principe draait accessibility om universal design, dat je iets ontwerpt waar iedereen gebruik van kan maken. Je zult dan ook vaak zien dat als je iets accessible maakt, het voor andere gebruikers ook fijner te gebruiken is. Toetsenbordtoegankelijkheid (veel punten waard bij scrabble) is daar een voorbeeld van.
En als je niet voor al je gebruikers ontwerpt, tja...

[crisp]

Karp schreef op vrijdag 10 augustus 2018 @ 14:00:
[...]

Accessibility issues zijn wel degelijk bugs.

Nee, het zijn tekortkomingen. Het is iets wat al in de (product-)designfase meegenomen moet worden, en ook technisch goed uitgedacht en uitgewerkt. Dat dat niet altijd gebeurt is niet altijd bewust, maar soms ook een kosten-baten afweging (voor minder kritische functionaliteit).

Aangezien bewustwording er in de hele keten moet zijn, beginnende bij de product-designfase voor nieuwe functionaliteit, lijkt mij dit forum beter geschikt dan het bugforum. Accessibility achteraf toevoegen (als ware het een bugfix) is meestal niet de beste methode.

[Mx. Alba]

crisp schreef op vrijdag 10 augustus 2018 @ 14:21:
Accessibility achteraf toevoegen (als ware het een bugfix) is meestal niet de beste methode.

Bezien vanuit het standpunt van iemand die accessibility nodig heeft is dat vast anders...

[ACM]

Karp schreef op vrijdag 10 augustus 2018 @ 14:00:
Accessibility issues zijn wel degelijk bugs.

Dat lijkt me niet, maar laten we daar verder niet over discussieren.

Je bent een deel van je gebruikers aan het buitensluiten wat in feite gewoon discriminatie is.

En zodra je op deze manier begint ga je natuurlijk gelijk al de hele sfeer verpesten en dwing je ons in een verweermodus.

Daarnaast wordt er eigenlijk gewoon incorrecte HTML gebruikt voor bijvoorbeeld de notificaties en priveberichten. Dat zouden buttons moeten zijn.

Over welke 'notificaties' en 'priveberichten' heb je het nu? Dat is nogal een brede term die op tientallen, zo niet honderden, plekken kan gelden. Kortom, als je ons wilt verwijten dat we html onjuist toepassen, help ons dan alsjeblieft ook met concrete aanwijzigen om het te verbeteren
Wij hebben simpelweg geen uitgebreide accessibitity-kennis in huis en zullen het dus nooit perfect kunnen doen zonder hulp.

De hele rechterbovensectie is nu niet te bedienen met het toetsenbord. Ga maar eens met je tab-toets door een paar pagina's van tweakers heen, en kijk eens hoeveel interactieve elementen je niet kan bereiken. Dat is echt zonde en zou niet hoeven.

Waarschijnlijk moet daarvoor dan wel die hele menu-interactie anders en hoewel het misschien niet zou hoeven, reikt mijn kennis niet ver genoeg om - zonder uitgebreid onderzoek te doen - te weten hoeveel lastiger het is om dat zowel met de muis als het toetsenbord logisch werkend te maken.

Ik ben heel benieuwd wat voor voorbeelden je kan noemen waar accessibility en usability tegenovergesteld zijn.

Het voorbeeld waarmee de topicstarter zelf al aankwam; sliders. Heel gebruiksvriendelijk voor mensen die kunnen zien waar de slider terecht komt en het geeft tegelijk een goede visualisatie voor het gekozen en uitgesloten bereik. En die kan je vast wel met toetsenbord-interactie uitrusten (pijltjestoets links/rechts bijv), maar ik zou niet weten hoe je daar dan gesproken tekst bij naar voren kan laten komen voor de positie...
Vervangen door een setje dropdowns of een invulvak voor losse waardes is uiteraard een optie, maar dan praat je wel weer over het complexer maken van de interface (zowel technisch als voor de gebruiker).

In principe draait accessibility om universal design, dat je iets ontwerpt waar iedereen gebruik van kan maken.

Zo simpel is het in de praktijk niet. En dat wordt bemoeilijkt doordat je veel van de interactieve dingen op sites met een programmeertaal moet doen die dan effectief een standaardinteractie overneemt en iets totaal anders doet (en je effectief dus ook de eventuele accessibilty laag van de browser deels teniet doet). En dat wordt natuurlijk niet beter als er ook niet zoveel kennis en top-of-mind aandacht voor is.

Je zult dan ook vaak zien dat als je iets accessible maakt, het voor andere gebruikers ook fijner te gebruiken is. Toetsenbordtoegankelijkheid (veel punten waard bij scrabble) is daar een voorbeeld van.
En als je niet voor al je gebruikers ontwerpt, tja...

Het is per definitie onmogelijk om het voor alle gebruikers goed te doen. En dan heb ik het niet over mensen met een handicap, maar je kan zat verschillende interpretaties van gebruikerswensen vinden die elkaar tegenwerken als je ze allen probeert uit te werken.

Kortom, we hebben niet zo heel veel aan iets dat in principe stelt "jullie doen het slecht" of zelfs "het moet van de wet beter". We hebben meer aan, "als je dit specifieke element verandert van een span naar een button, dan verandert er voor de gewone gebruiker niets en verandert dat specifieke ding van onbruikbaar naar best goed bruikbaar voor mensen met een handicap".

Of anders gezegd; als je iets een bug vindt, probeer dan een zo behulpzaam mogelijke bugmelding ervan te maken

[Mx. Alba]

Volgens mij is een heel simpele test die elke ziende ook kan doen, om te checken of je alles kand doen wat je moet kunnen doen op de site in een keyboard-gestuurde text-only-browser zoals Lynx: https://lynx.invisible-island.net/current/index.html

[Karp]

crisp schreef op vrijdag 10 augustus 2018 @ 14:21:
[...]

Nee, het zijn tekortkomingen. Het is iets wat al in de (product-)designfase meegenomen moet worden, en ook technisch goed uitgedacht en uitgewerkt. Dat dat niet altijd gebeurt is niet altijd bewust, maar soms ook een kosten-baten afweging (voor minder kritische functionaliteit).

Aangezien bewustwording er in de hele keten moet zijn, beginnende bij de product-designfase voor nieuwe functionaliteit, lijkt mij dit forum beter geschikt dan het bugforum. Accessibility achteraf toevoegen (als ware het een bugfix) is meestal niet de beste methode.

Dat is iets waar we het zeker over eens kunnen zijn. Accessibility toepassen is iets wat je begint bij bewustwording, "awareness". En het is ook zeker het beste om dit van begin af aan te doen. Maar daar hebben de gebruikers nu natuurlijk niks meer aan, dus uiteindelijk zijn die bugfixes wel zeer welkom.

[Karp]

ACM schreef op vrijdag 10 augustus 2018 @ 15:46:
[...]

Dat lijkt me niet, maar laten we daar verder niet over discussieren.


[...]

En zodra je op deze manier begint ga je natuurlijk gelijk al de hele sfeer verpesten en dwing je ons in een verweermodus.


[...]

Over welke 'notificaties' en 'priveberichten' heb je het nu? Dat is nogal een brede term die op tientallen, zo niet honderden, plekken kan gelden. Kortom, als je ons wilt verwijten dat we html onjuist toepassen, help ons dan alsjeblieft ook met concrete aanwijzigen om het te verbeteren
Wij hebben simpelweg geen uitgebreide accessibitity-kennis in huis en zullen het dus nooit perfect kunnen doen zonder hulp.


[...]

Waarschijnlijk moet daarvoor dan wel die hele menu-interactie anders en hoewel het misschien niet zou hoeven, reikt mijn kennis niet ver genoeg om - zonder uitgebreid onderzoek te doen - te weten hoeveel lastiger het is om dat zowel met de muis als het toetsenbord logisch werkend te maken.


[...]

Het voorbeeld waarmee de topicstarter zelf al aankwam; sliders. Heel gebruiksvriendelijk voor mensen die kunnen zien waar de slider terecht komt en het geeft tegelijk een goede visualisatie voor het gekozen en uitgesloten bereik. En die kan je vast wel met toetsenbord-interactie uitrusten (pijltjestoets links/rechts bijv), maar ik zou niet weten hoe je daar dan gesproken tekst bij naar voren kan laten komen voor de positie...
Vervangen door een setje dropdowns of een invulvak voor losse waardes is uiteraard een optie, maar dan praat je wel weer over het complexer maken van de interface (zowel technisch als voor de gebruiker).


[...]

Zo simpel is het in de praktijk niet. En dat wordt bemoeilijkt doordat je veel van de interactieve dingen op sites met een programmeertaal moet doen die dan effectief een standaardinteractie overneemt en iets totaal anders doet (en je effectief dus ook de eventuele accessibilty laag van de browser deels teniet doet). En dat wordt natuurlijk niet beter als er ook niet zoveel kennis en top-of-mind aandacht voor is.


[...]

Het is per definitie onmogelijk om het voor alle gebruikers goed te doen. En dan heb ik het niet over mensen met een handicap, maar je kan zat verschillende interpretaties van gebruikerswensen vinden die elkaar tegenwerken als je ze allen probeert uit te werken.

Kortom, we hebben niet zo heel veel aan iets dat in principe stelt "jullie doen het slecht" of zelfs "het moet van de wet beter". We hebben meer aan, "als je dit specifieke element verandert van een span naar een button, dan verandert er voor de gewone gebruiker niets en verandert dat specifieke ding van onbruikbaar naar best goed bruikbaar voor mensen met een handicap".

Of anders gezegd; als je iets een bug vindt, probeer dan een zo behulpzaam mogelijke bugmelding ervan te maken

Mijn scherpe reactie was omdat ik Tweakers zie als een website die voor wil lopen, en zich richt op de techniek. Ik heb hier vroeger veel geleerd en gelezen. Als ik dan zie dat er een hele bevolkingsgroep is die niet of slecht toegang heeft tot die zelfde mogelijkheden, dan vind ik dat erg jammer. Zeker omdat het technisch gezien prima mogelijk is om die mensen niet buiten te sluiten.


Ik kan wel wat preciezer zijn, maar als je een uitgebreid verslag wil dan doe ik waar ik normaal gesproken voor betaald krijgt

Ik had het over de 'userbar', waar het volgens mij in dit topic ook over ging. Daarin wordt een <a> gebruikt zonder href maar met een click-event. Dit element is bedoelt voor navigatie, zowel tussen als op pagina's. Daarnaast is het zonder href ook niet benaderbaar met een toetsenbord. Een betere semantische oplossing is om hier een button voor te gebruiken. Die is er voor bedoeld om acties uit te voeren, en is standaard al met toetsenbord te benaderen. En wil je de gebruiker helemaal blij maken, dan zet je er ook nog aria-haspopup op:
Als je het daadwerkelijke element dat tevoorschijn komt ook toegankelijk wil maken, dan moet je ook nog de focus vangen. Zoals je dat ook met een modal dialog zou doen. Dat betekent dat je met je tab toets niet uit dit element kan. Dat is voor een enkel menu wel even onderzoek, maar eenmaal uitgezocht kun je dit patroon op heel veel plekken herhalen.

Een slider is inderdaad ook prima toegankelijk te maken. Je moet er misschien even induiken, maar je wordt geen developer als je niet van een uitdaging houdt toch? Uiteindelijk is accessibility ook gewoon een kwestie van technisch perfecte producten maken.

Mocht je het een interessante uitdaging vinden dan kun je bijvoorbeeld beginnen met het installeren van aXe. Dat is een browser extensie die een aantal (lang niet alle) accessibility issues voor je kan vinden. Een goede simpele checklist kan je ook helpen.
Probeer je website eens te bedienen met alleen je toetsenbord. Of leer een screen reader te gebruiken. Als je een android of ios apparaat hebt, dan heb je er altijd eentje voor handen.
Er zijn ook tal van MOOC's die de moeite waard zijn. Van Google bijvoorbeeld of als je iets uitgebreiders zoekt, van Deque, de maker van aXe.
Al is het wel het makkelijkst om snel op gang te komen (zowel als website, als persoonlijk) als je iemand voor handen hebt die al kennis in huis heeft. Als je het echt 100% goed wilt doen is het toch een flinke kluif, maar het begint bij bewustzijn en bereidheid.

[ACM]

Karp schreef op vrijdag 10 augustus 2018 @ 17:48:
Mijn scherpe reactie was omdat ik Tweakers zie als een website die voor wil lopen, en zich richt op de techniek. Ik heb hier vroeger veel geleerd en gelezen. Als ik dan zie dat er een hele bevolkingsgroep is die niet of slecht toegang heeft tot die zelfde mogelijkheden, dan vind ik dat erg jammer. Zeker omdat het technisch gezien prima mogelijk is om die mensen niet buiten te sluiten.

Bedankt voor deze erg behulpzame reactie

En dit zijn we uiteraard met je eens, maar helaas hebben ook wij eindige tijd, kennis en mogelijkheden. En daardoor zijn er diverse zaken die minder aandacht krijgen, waaronder - helaas - een van de veel te gebruikelijke zaken als de accessibility.

Ik kan wel wat preciezer zijn, maar als je een uitgebreid verslag wil dan doe ik waar ik normaal gesproken voor betaald krijgt

Dat snap ik

Je moet er misschien even induiken, maar je wordt geen developer als je niet van een uitdaging houdt toch? Uiteindelijk is accessibility ook gewoon een kwestie van technisch perfecte producten maken.

Uiteraard, hoewel ik persoonlijk meer bezig ben met de achterkant (zoals ervoor zorgen dat de benodigde data voor die sliders (snel) wordt geleverd)