axe Developer Hub Woordenlijst

This page is not available in the language you requested. You have been redirected to the English version of the page.
Link to this page copied to clipboard

Termen die nuttig zijn voor het begrijpen van axe Developer Hub

Not for use with personal data

a11y

Nummer-gebaseerde afkorting (of numeroniem) voor het woord „toegankelijkheid“, met „11“ (elf) dat het aantal karakters vertegenwoordigt tussen de begin-„a“ en eind-„y“ in toegankelijkheid. Uitgesproken als ally.

API-sleutel

Voor autorisatie genereert u een API-sleutel in Axe Accountinstellingen. U kunt dezelfde API-sleutel gebruiken voor meerdere projecten, hoewel u een Axe Developer Hub API-sleutel alleen voor webprojecten en een Axe DevTools Mobile API-sleutel alleen voor mobiele projecten moet gebruiken.

Axe Developer Hub

Axe Developer Hub stelt u in staat om nieuwe testprojecten aan te maken en toont u de resultaten van uw toegankelijkheidstestuitvoeringen. U kunt zoveel projecten aanmaken als u nodig heeft om toegankelijkheid op uw websites en mobiele apps te bekijken en te beheren.

Best Practices

Deque best practices zijn beproefde technieken die gewenste toegankelijkheidsresultaten opleveren wanneer specifieke formele methoden ontbreken of onvoldoende zijn. Hoewel ze officieel niet zijn opgenomen in enige vastgestelde toegankelijkheidsregels, kan het volgen van Deque's best practices de toegankelijkheid en algehele kwaliteit van de geteste webpagina verbeteren. Het moet worden opgemerkt dat niet-naleving van Deque's richtlijnen voor best practices niet automatisch een mislukking betekent. Bovendien is deskundig oordeel vereist om de geschiktheid te beoordelen in de context van de doelen van de toepassing, site of pagina. Soms is de techniek voor beste toegankelijkheidspraktijk niet van toepassing of praktisch voor het oplossen van een specifiek probleem. Zie Best Practices voor de regels die de set van best practices vormen.

Build-ID

De build-ID wordt automatisch gegenereerd als een UUID wanneer deze niet door de gebruiker wordt verstrekt, en wordt gebruikt om scans aan elkaar te koppelen als een enkele testsessie. Bij het uitvoeren van een testsuite op meerdere machines of omgevingen, zal het verstrekken van een build-ID ervoor zorgen dat alle van deze uitvoeringen aan elkaar worden gekoppeld en als een enkele sessie in Developer Hub worden weergegeven.

Duplicaat

Een duplicaat is hetzelfde toegankelijkheidsprobleem dat op dezelfde document object model (DOM) node in meerdere pagina toestandenwordt gezien. Als u een probleem met duplicaten oplost, verdwijnen al zijn duplicaten omdat het allemaal hetzelfde probleem betreft.

e2e Testing

End-to-end, of e2e, testen verwijst naar het testen van de volledige functionaliteit van de webapplicatie door het testen van de implementatie in de echte wereld. Met Axe Developer Hub kunt u e2e-scenario's testen op toegankelijkheidsproblemen.

Experimentele Regels

Experimentele regels worden nog steeds ontwikkeld en getest om nieuwe technologieën aan te pakken of om een beter begrip en bewustzijn van toegankelijkheidsproblemen te vergroten. Deze regels moeten niet worden vertrouwd in productieomgevingen omdat ze nog in ontwikkeling zijn en gevoelig voor valse positieven. Uiteindelijk kunnen regels in deze regels set deel gaan uitmaken van toegankelijkheidsstandaarden. Experimentele regels zijn standaard uitgeschakeld. Zie Experimentele Regels voor de regels die deze regels set vormen in de nieuwste versie van axe-core.

Git

Veel Developer Hub-projecten hebben testsuites die gebruikmaken van een Git repository. Het gebruik van Git stelt je in staat om toegankelijkheidsdefecten aan code op verschillende branches en in specifieke commits te koppelen, wat helpt bij hun oplossing.

Gitless

Gitless verwijst naar een Developer Hub-project met een testsuite die geen gebruikmaakt van een Git-repository. Hoewel niet verplicht, stelt een Git-repository je in staat om toegankelijkheidsdefecten aan specifieke codewijzigingen te koppelen, wat helpt bij hun oplossing.

Impact

Een impact niveau wordt toegewezen aan elke toegankelijkheidsschending, gecategoriseerd in vier niveaus van minst tot meest impactvol: klein, matig, ernstig, en kritiek. Deze metric helpt bij het prioriteren van herstelwerkzaamheden, en Deque-toegankelijkheidsexperts wijzen standaard een impactniveau toe aan elk type overtreding.

Defecten met ernstig of kritiek impactniveaus vormen aanzienlijke of onoverkomelijke barrières voor gebruikers met een beperking, met de hoogste juridische aansprakelijkheid. Hoewel kleine en matige problemen niet zo ernstig zijn, zijn ze nog steeds cruciaal voor naleving en het tegemoetkomen aan de behoeften van mensen met beperkingen.

De vier niveaus die worden gebruikt om de impact van toegankelijkheidsproblemen te categoriseren zijn:

  1. Klein: Problemen die gebruikers met beperkingen minder treffen dan matige problemen, maar die toch moeten worden opgelost voor volledige naleving.

  2. Matig: Er bestaan enkele barrières voor gebruikers met beperkingen, maar zouden hen niet verhinderen toegang te krijgen tot basisinhoud of -stromen. Deze problemen kunnen uw organisatie kwetsbaar maken voor juridische stappen en moeten worden gerepareerd voordat volledige naleving wordt bereikt.

  3. Ernstig: Gebruikers met beperkingen zullen aanzienlijke barrières ondervinden bij interactie met de site, wat frustratie veroorzaakt en het moeilijk maakt gerelateerde inhoud te benaderen. Herstel moet een hoge prioriteit hebben om juridische stappen te vermijden.

  4. Kritiek: Gebruikers met beperkingen worden volledig geblokkeerd van toegang tot of interactie met een functie op de webpagina, waardoor de inhoud ontoegankelijk wordt en uw organisatie zeer kwetsbaar is voor rechtszaken. Herstel van kritieke problemen moet een topprioriteit zijn.

Gewijzigde Testsuite

Een gewijzigde testsuite is een testsuite die je hebt veranderd volgens de instructies van Axe Developer Hub toen je een nieuw project creëerde. Het aanpassen van je testsuite stelt je in staat om toegankelijkheidstests toe te voegen aan je bestaande testsuite met minimale wijzigingen aan de testsuite zelf.

Organisatorisch Beheerder

Een organisatorisch beheerder (org admin) is een gebruiker met administratieve rechten voor hun hele onderneming in Axe Account. Org admins kunnen alle projecten in hun onderneming bekijken en projectleden en instellingen beheren, ongeacht of ze lid zijn van een bepaald project. Org admin-status heeft voorrang boven projectniveau-rollen. Org admins moeten een actieve Axe Developer Hub of Axe DevTools for Mobile-licentie hebben om nieuwe projecten te creëren of resultaten naar Axe Developer Hub te sturen, maar ze kunnen bestaande projecten beheren zonder licentie.

Pagina Status

De pagina status verwijst naar de staat van het documentobjectmodel (DOM) van een webpagina op een specifiek moment. Het bekijken van verschillende paginastatussen is nuttig voor complexe websites met inlogschermen of dynamische UI, zoals single-page applicaties (SPA's). Voorbeelden van DOM-status zijn onder meer:

  • De zichtbaarheid van elementen
  • De inhoud van elementen
  • De geselecteerde status van keuzerondjes en selectievakjes

Bij gebruik van Watcher scant het pakket webpagina's opnieuw telkens wanneer het wijzigingen aan de DOM detecteert en slaat het elke keer een nieuwe paginastatus op.

Project

Een **project** in Axe Developer Hub bevat toegankelijkheidsresultaten, informatie over testuitvoeringen en Git-gegevens (takken en commits). U maakt en benoemt een nieuw project in Developer Hub, wat een Project-ID creëert om te gebruiken bij uw tests om het project te identificeren en de resultaten te koppelen aan het project.

Projectbeheerder

Een **projectbeheerder** is een projectlid met verhoogde rechten. Projectbeheerders kunnen alles doen wat een projectlid kan, plus projectinstellingen beheren, leden toevoegen of verwijderen en ledenrollen wijzigen. Bij het gebruik van Axe Watcher is de API-sleutel van een projectbeheerder vereist om tests in een pipeline uit te voeren.

Project-ID

Een **Project-ID** wordt automatisch gegenereerd wanneer u een nieuw project toevoegt, om uw resultaten te koppelen aan dat project. Zowel een Project-ID als een API-sleutel zijn vereist om toegankelijkheidsresultaten naar Developer Hub te verzenden. Het is het beste om één project-ID aan één test suite/repository te koppelen, om de toegankelijkheidsstatus van uw project nauwkeuriger bij te houden.

Projectlid

Een **projectlid** is een gebruiker die is toegevoegd aan een Axe Developer Hub-project. Projectleden kunnen tests uitvoeren en resultaten binnen het project bekijken. Leden moeten een actieve licentie hebben om toegang te krijgen tot het project.

SHA

Wanneer u een commit maakt met Git, creëert dit een ID om de commit uniek te identificeren. Deze unieke ID wordt een **SHA** genoemd (vernoemd naar de Secure Hash Algorithms, een groep cryptografische hashfuncties).

Tag

Een **tag** groepeert regels die behoren tot een specifieke toegankelijkheidsrichtlijn, zoals WCAG. Voor meer informatie over de regels en de tags waartoe deze regels behoren, zie axe-core Regelsbeschrijvingen

WCAG

**WCAG**, of *Web Content Accessibility Guidelines*, zijn een set richtlijnen ontwikkeld door het World Wide Web Consortium (W3C) om webinhoud toegankelijker te maken voor mensen met een handicap. Deze richtlijnen bieden een kader voor het creëren van toegankelijke websites en digitale inhoud die door mensen met een breed scala aan handicaps kan worden gebruikt.

De drie conformiteitsniveaus van WCAG worden gedefinieerd door een set succescriteria die specifieke elementen van webinhoud beschrijven die moeten worden voldaan om dat niveau van conformiteit te bereiken. Conformiteitsniveau A is het minimale niveau van conformiteit, terwijl conformiteitsniveau AAA het meest stringente is. Conformiteitsniveau AA vereist conformiteit met zowel niveau A als niveau AA succescriteria. Conformiteit met alle drie de niveaus van succescriteria (A, AA en AAA) is vereist voor conformiteit met niveau AAA.

WCAG 1.0 was de eerste versie van deze richtlijnen en werd gepubliceerd in 1999. WCAG 2.0 werd gepubliceerd in 2008 en bood meer uitgebreide richtlijnen voor het toegankelijk maken van webinhoud voor mensen met een grotere verscheidenheid aan handicaps.

WCAG 2.1 werd gepubliceerd in 2018. Het bouwt voort op de vorige versies en bevat nieuwe succescriteria om toegankelijkheidsproblemen aan te pakken die zijn ontstaan sinds de release van WCAG 2.0. WCAG 2.1 biedt ook meer richtlijnen voor mobiele toegankelijkheid, toegankelijkheid voor mensen met een beperkt gezichtsvermogen en cognitieve en leerstoornissen.

WCAG 2.2, de meest recente versie van deze richtlijnen, werd gepubliceerd in 2023 en biedt negen nieuwe succescriteria bovenop WCAG 2.1. Het biedt verbeterde richtlijnen voor het aanpakken van de behoeften van gebruikers met cognitieve of leerstoornissen, gebruikers met een beperkt gezichtsvermogen en gebruikers met handicaps op mobiele apparaten. Het is achterwaarts compatibel met WCAG 2.1.