1.4.4 Testen bij een resolutie van 1024x768?

[gjccopinga]

Van oudsher hebben we altijd SC 1.4.4 getest bij een resolutie van 1024x768 en dan inzoomen tot 200%. Ik vroeg me af of deze testmethode ook door iedereen zo gehanteerd wordt of niet. Het gaat dan specifiek om de resolutie keuze van 1024x768. Is dit (nog steeds) een van de manieren om dit te testen?

[RenateRoke]

Moest even zoeken waar het precies vandaan kwam, maar gevonden: https://www.w3.org/WAI/WCAG21/Techniques/failures/F94.html, 1280 breed (1280 bij 1024 dan) of de vergrootfunctie van de site zelf. Maar als er andere opties zijn ben ik ook wel benieuwd naar het hoe en waarom daarvan.

[Aircl0wn]

Het jammer hier is dat zoomen inderdaad adequaat genoeg is. Het gebruik van grotere lettertypes (firefox text resize e.d.) gaan dingen toch vaak stuk. Ik plaats daar dan wel een opmerking over.

[ShadowBB]

Goede vraag Gerard!

Om de discussie voor deze GitHub even op scherp te stellen, stel ik voor om een scenario er aan toe te voegen:

Stel er is een stuk content dat verdwijnt als de gebruiker 200% inzoomed op 1024 schermbreedte. Datzelfde stuk content verdwijnt niet als de gebruiker 200% inzoomed op 1280 schermbreedte. Moet dit goedgekeurd worden of afgekeurd worden?

Als je het met dit scenario eens bent, kun je hem dan toevoegen aan je opening post?

[ShadowBB]

Dan mijn antwoord:

Het SC zelf eist helemaal geen start schermbreedte en gaat er dus vanuit dat er een Accessibility Baseline gedefinieerd wordt tijdens een audit (zoals beschreven in WCAG-EM https://www.w3.org/TR/WCAG-EM/#step1c) om te bepalen of het voldoet of niet aan de "accessibility support" conformance eis wat nodig is om aan WCAG te voldoen.

Al snel na het schrijven van dit SC op deze manier zorgde dit voor bovenstaande discussies en problemen. Het W3C wilt helemaal geen accessibility support baseline definiëren (zie ook de andere discussies op deze GitHub) en laat dit over aan beleidsmakers. Beleidsmakers zijn of onwetend over deze zaak of zijn niet bereid om hier uitspraken over te doen omdat ze dan als overheid de markt beïnvloeden. Dus die laten dit (ook in het geval van Logius) over aan de consensus van de nationale markt.

Lang geleden is voor Nederland die consensus gevallen op 512 (1024/2), relatief arbitrair gekozen op basis van de beschikbare beeldschermen.

In 2016 is F94 toegevoegd (na onze Nederlandse consensus) die suggereert dat het 640 (1280/2) zou moeten zijn. Maar ik verwacht dat dit eerder een poging is om te stellen "dit is het absolute minimum, als je dit al niet haalt weten we zeker dat het fout is" poging is. Nederland hield in ieder geval vast aan de 512 consensus. Er zijn ook stemmen die stellen dat die 1280 beginsituatie uit die techniek gehaald moet worden: https://github.com/w3c/wcag/issues/704 https://github.com/w3c/wcag/pull/1838

Mijn conclusies is "meh.... het wordt toch afgekeurd onder reflow, so who cares?"

1.4.10 Reflow eist dat content niet mag verdwijnen bij een resolutie van 320 CSS pixels (wat gelijk is aan 1280 400% ingezoomed... of dus 640 200% ingezoomed).

Dus ik heb er geen moeite mee om die failure techniek te volgen en vanaf dit moment dit scenario dus goed te keuren. Aangezien de situatie opgevangen wordt door 1.4.10.

[ShadowBB]

@gjccopinga Ben jij het eens met dat we mijn scenario pakken als datgene waar we over twijfelen? En beantwoord mijn antwoord jou vraag? Dan volgen we de failure techniek van @RenateRoke en dan hebben we volgens mij een consensus.

[gjccopinga]

@ShadowBB Ik ben het eens met het scenario wat je hebt geschetst. Is een goede situatieschets. En ja, jouw vraag beantwoord mijn vraag. En ja, ik ben voorstander van het volgen van de toetsmethode die in de failure techniek beschreven staat.

[ShadowBB]

Top! Als jij dan binnen nu en 10 dagen ergens een conclusie kunt typen voor op de website zou dat helemaal mooi zijn. Anders type ik die na 10 dagen.

[armenos]

Zelf onderzoek ik altijd op resolutie van 1024x768 en daarna zoom ik op 200%. Op deze manier hebben we altijd onderzocht. Echter, dit zou geen reden zijn om op deze manier te blijven doen. Ik verwijs graag naar G178 techniek. https://www.w3.org/WAI/WCAG21/Techniques/general/G178.html Zo zijn er meerdere technieken waar net op een andere manier getest kan worden. Volgens mij hebben wij ooit deze beslissing genomen als een soort minimum van testmethode. Met deze testmethode kunnen wij altijd hetzelfde resultaat behalen en kunnen we een andere partij uitleggen hoe een test uitgevoerd wordt. Als dit nu achterhaald blikt te zijn dan moeten we een duidelijke omschrijving hebben voor een testmethode voor SC 1.4.4. Ik heb zelf ook geen moeite om F94 te volgen, ik hoop dat de hoogte van het scherm dan geen verschillen in testresultaten oplevert. Dit zeg ik omdat bij F94 wordt alleen over de breedte van het scherm gesproken en niet over de hoogte.

[Aircl0wn]

De oorsprong van dit SC ligt in de tijd dat browser zoom nog geen ding was. pas sinds de tijd daarna is die mogelijkheid erbij gekomen.

Het SC eist alleen maar dat het mogelijk is de originele tekstgrootte (dus de standaard presentatie op 100% weergave) verdubbeld kan worden naar 200%, ongeacht of daarmee de rest van de weergave meeschaalt of niet. Hoewel de UD/ technieken hier een weergave noemen is die grootte niet bepalend voor de toetsing. Zolang die tekst maar op 200% kan worden weergegeven wordt aan het criterium voldaan.

icm met 1.4.10 doe ik tegenwoordig in de basis dit totdat ik problemen tegenkomt: https://github.com/w3c/wcag21/issues/883#issuecomment-384800487

Dat omvat uiteindelijk ook F94, ik lsuit me dus aan bij passed

[armenos]

Ik zal voortaan ook de F94 techniek hanteren voor SC 1.4.4.

[ShadowBB]

Prachtig! Dan zijn we het eens met zen allen. @gjccopinga kun jij een conclusie schrijven voor de website?

[julezrulez]

Ik ga voortaan ook voor 1280px breed, dus F94.