SaaS is gemeengoed voor veel instellingen en bedrijven geworden. We onderzoeken welke implicaties Saas kan hebben voor de toegankelijkheid voor mensen Met Een handicap. Met name het gebruik voor interactieve webpagina’s.
door: Kath Moonan, AbilityNet. 2021 Update door ITpedia redactie
Wat is SaaS?
De term SaaS verwijst naar hogere generatie services die beschikbaar Zijn op het World Wide Web. Daarmee kunnen mensen online samenwerken en informatie kunnen delen. Veel ERP pakketten zijn tegenwoordig als SaaS toepassing te verkrijgen.
Webtechnologieën zijn in de loop van de tijd geëvolueerd en kunnen als volgt worden gecategoriseerd:
- Web1.0 statische webpagina’s met informatie over diverse onderwerpen.
- Web1.5 Content Management System (CMS)-gestuurde websites waarmee gebruikers informatie kunnen manipuleren.
- Web2.0 volledig responsieve webapplicaties die desktopprogramma’s nabootsen – en waarmee gebruikers ook informatie kunnen opslaan en delen via het netwerk.
- Web3.0 Semantisch web. Web 3.0 gaat een stap verder dan Web 2.0 door ook de inhoud van die documenten te begrijpen.
- Web4.0 Staat bekend als het symbiotische web. Het doel van het symbiotische web is de symbiotische interactie tussen mens en machine. De grens tussen mens en machine zal vervagen. The Internet of Things en AI.
Vanaf Web 2.0 spreken we van SaaS toepassingen.
Toegankelijkheid is een probleem voor mensen met een handicap
Er zijn een aantal issues met toegankelijkheid bij SaaS toepassingen die problemen kunnen veroorzaken voor gehandicapte internetgebruikers. Dit komt voornamelijk omdat veel van deze software is gebouwd zonder veel aandacht voor toegankelijkheid. Een belangrijk probleemgebied is bijvoorbeeld Ajax, dat problemen kan veroorzaken voor gebruikers van schermlezers.
De soorten problemen waarmee mensen met een handicap te maken kunnen krijgen, zijn onder meer:
- Ontoegankelijke inlogboxen of Two-Factor tests zonder alternatieven zoals audio.
- Ontoegankelijke WYSIWYG-editors die niet compatibel zijn met ondersteunende technologieën of alleen werken met een muis of aanwijsapparaat. In plaats daarvan moeten we het toetsenbord altijd kunnen gebruiken. Dit maakt het voor alle gebruikers mogelijk is om tekst te maken of te bewerken.
- Ontoegankelijke interfaces die afhankelijk zijn van slepen en neerzetten (interactie met een vinger, muis of aanwijsapparaat) zonder alternatieve toetsenbord-optie.
- Gebruikers van schermlezers worden niet gewaarschuwd wanneer inhoud dynamisch is gewijzigd zonder de pagina te vernieuwen (met name Ajax).
- Ontoegankelijke inhoud die gebruikers hebben gemaakt, zoals:
- Inhoud gemaakt zonder semantische code, die niet-visuele informatie over de inhoud geeft. Dit is vooral handig is voor gebruikers van schermlezers.
- Afbeeldingen zijn opgenomen zonder alt-tekst.
- Er zijn stijlen en ontwerpen gebruikt die moeilijk of onmogelijk te lezen zijn.
- Rich media is inbegrepen zonder bijschriften of alternatieven.
- Ontoegankelijke bedieningselementen op audio- of videospelers die niet compatibel zijn met ondersteunende technologieën of die afhankelijk zijn van het gebruik van een muis of aanwijsapparaat.
- Gebruikers worden niet gewaarschuwd voor toegankelijkheidsproblemen bij het invoeren van inhoud.
De toegankelijkheid van een SaaS toepassing
Als we overwegen om een SaaS toepassing te gebruiken voor onze gebruikers, moeten we zeer goed letten op de toegankelijkheid van deze software.
Aangezien de meeste SaaS toepassingen het schrijven van inhoud toestaan, vallen ze onder de ATAG-richtlijnen (Authoring Tool Accessibility Guidelines) en de WCAG-richtlijnen (Web Content Accessibility Guidelines).
De belangrijkste controlepunten van ATAG zijn onder meer:
- Ondersteuning van toegankelijke schrijfmethoden.
- Standaard opmaak genereren.
- Ondersteun de creatie van toegankelijke inhoud.
- Bied manieren om ontoegankelijke inhoud te controleren en te corrigeren.
- Integreer toegankelijkheidsoplossingen in de algehele “look and feel”.
- Toegankelijkheid bevorderen in Helpschermen en documentatie.
- Zorg ervoor dat de SaaS applicatie toegankelijk is voor auteurs met een handicap.
We gebruiken deze richtlijnen om de toegankelijkheid te beoordelen van de applicaties die we bekijken voordat we ze aanschaffen of implementeren.
Technische problemen met Ajax (voor ontwikkelaars)
Ajax is een afkorting voor Asynchronous JavaScript en XML, het is een webontwikkelingstechniek voor het maken van interactieve webapplicaties. Het doel is om webpagina’s meer responsive te laten voelen door kleine hoeveelheden data uit te wisselen met de onderliggende cloudservers. Hierdoor hoeft de hele webpagina niet telkens opnieuw te worden geladen als de gebruiker om een wijziging vraagt.
Bekende toegankelijkheidsproblemen
- JavaScript uitgeschakeld. Als een gebruiker JavaScript heeft uitgeschakeld, worden er geen oproepen gedaan om informatie op te halen. Als er geen alternatief is geboden, kan het zijn dat de gebruiker de webpagina niet meer kan blijven gebruiken.
- De gebruiker waarschuwen dat een pagina is bijgewerkt. Als een Ajax-aanroep met succes is gedaan, zal deze doorgaans enkele gegevens van de server retourneren en bepaalde elementen op de pagina bijwerken (door html-tags te vervangen of te wijzigen). Daarbij blijft de rest van de pagina intact. Voor mensen met een goed gezichtsvermogen is deze verandering misschien duidelijk. Dit is echter niet altijd het geval, aangezien Ajax-oproepen vaak erg snel zijn en gemakkelijk worden gemist. Het zal het zeker niet duidelijk zijn voor degenen die een schermlezer gebruiken. Sommige schermlezers, zoals de IBM Home Page Reader, ondersteunen JavaScript en kunnen zelfs de bijgewerkte html-elementen lezen. Ze zullen een gebruiker echter niet informeren dat een deel van de pagina is bijgewerkt.
Wat kunnen we doen om deze problemen met toegankelijkheid op te lossen?
Het is te hopen dat zowel fabrikanten van browsers als van schermlezers zullen werken aan oplossingen voor deze problemen. Dat kan door te detecteren wanneer een pagina is bijgewerkt via een Ajax-oproep. Inmiddels zijn er ook een aantal technieken die ontwikkelaars kunnen gebruiken. We moeten echter toegeven dat er op dit moment geen duidelijke en simpele oplossing is, dus maak op dit moment spaarzaam gebruik van Ajax technieken in SaaS toepassingen.
Ajax Toegankelijkheid – Goede Praktijk
Volg de “HIJAX” principes. Dit is gebaseerd op het idee van progressieve verbetering op vrijwel dezelfde manier als CSS, omdat de Ajax-functies een extra en optionele laag bovenop de HTML-opmaak moeten vormen:
- Bouw een traditionele webtoepassing die gebruikmaakt van hyperlinks en formulieren om informatie door te geven aan de cloudserver. De cloudserver retourneert bij elk verzoek geheel nieuwe pagina’s.
- Voeg JavaScript toe om die links en formulierinzendingen te onderscheppen en geef de informatie in plaats daarvan door via XMLHttpRequest. We kunnen dan selecteren welke delen van de pagina we moeten bijwerken in plaats van de hele pagina bij te werken. Meer informatie is te vinden op: http://adactio.com/journal/959.
- Maak onopvallend JavaScript. Dit is een techniek die alle JavaScript in een apart bestand opslaat en alleen wordt gebruikt door browsers die het script ondersteunen. Het idee is dat de pagina (zoals in HIJAX hierboven) moet kunnen functioneren zonder het *.js-bestand. Dit omvat zelfs het verwijderen van gebeurtenishandlers zoals OnClick, OnBlur enzovoort naar een functie in het *.js-bestand die door zal gaan en deze aan elementen zal toevoegen als JavaScript beschikbaar is.
- Informeer de gebruiker bovenaan het formulier dat JavaScript nodig is of detecteer JavaScript automatisch en waarschuw de gebruiker wanneer het niet beschikbaar is. Als het formulier veel velden heeft, besparen we onze gebruikers een hoop frustratie. Iedereen heeft een hekel aan het invullen van een formulier om erachter te komen dat ze het niet kunnen indienen.
- Informeer de gebruiker dat de pagina dynamisch wordt bijgewerkt. Dit is vooral belangrijk voor gebruikers van schermlezers en helpt hen te beslissen wanneer ze de pagina opnieuw moeten lezen. Het is misschien mogelijk om de focus()-methode in JavaScript te gebruiken, maar alleen bepaalde elementen (meestal op het formulier) ondersteunen dit en niet alle schermlezers.
- Gebruik waar nodig waarschuwingen. Maak het mogelijk om een melding te ontvangen wanneer informatie wordt bijgewerkt. Dit is misschien niet mogelijk, afhankelijk van de complexiteit van uw formulier, maar zal een gebruiker van een schermlezer veel helpen. Waarschuwingsvensters worden gelezen door de schermlezer en worden meestal samen met een geluid weergegeven. Het selectievakje moet worden weergegeven, zodat het duidelijk is dat het geen deel uitmaakt van het oorspronkelijke formulier.
- Gebruik het kenmerk Rol. Hoewel niet door alle schermlezers ondersteund, is dit een W3C-aanbeveling die de rol(len) beschrijft die het huidige element speelt in de context van het document. Bijvoorbeeld definieert de hoofdinhoud van een document en
Voorbeelden van slechte Ajax-toegankelijkheid
- Site die afhankelijk is van Ajax om te kunnen functioneren en geen alternatief biedt.
- Bijvoorbeeld inline scripting gebruiken en rechtstreeks coderen in een onChange-gebeurtenis.
- Sites die afhankelijk zijn van drag and drop of muisacties en geen toetsenbordalternatief hebben.
Dus wat is belangrijk voor een goede toegankelijkheid?
Volg de WCAG. Het is er allemaal. Zie Joe Clarke’s talk over Ajax voor een mooie samenvatting van de specifieke richtlijnen die horen bij scripting.
bronnen
SaaS en Ajax
Wikipedia-definitie van Web 2.0
Wikiepedia-definitie van Ajax
Auteurstool Richtlijnen voor toegankelijkheid van inhoud
Juicy Studios laat Ajax werken met schermlezers
ATAG beoordeling van WordPress
Waarom zijn blogs zo ontoegankelijk?
Is Ajax Toegankelijk? Helemaal? -Joe Clarke
Ajax en schermlezers: wanneer kan het werken?
Roadmap voor toegankelijke rich internet-applicaties (WAI-ARIA Roadmap)
Over de auteur
Kath Moonan, AbilityNet
AbilityNet is een nationale liefdadigheidsinstelling die gehandicapte volwassenen en kinderen helpt bij het gebruik van computers en internet door hun technologie aan te passen en aan te passen.Het oorsponkelijke artikel stond op www.ictknowledgebase.org.uk/
Discussieer mee op LinkedIn. Gerelateerde artikelen
