Het verbeteren van de Toegankelijkheid van de 24 manieren

0
72

Ik heb de laatste tijd nagedacht over de aard van mijn werk en aan welke aspecten van het ik het meest geniet. In een rol die vaak dwars over de werelden van ontwerp en ontwikkeling, zowel in het bewerken kopiëren, het evalueren van het ontwerp van een interface of code refactoring, ik ben gekomen om te beseffen dat mijn interesses liggen in de akte van herziening en verfijning.

Mijn werk op 24 manieren is geval in punt. Sinds Trok McLellan mij gevraagd om een redesign van de site in 2013, ik heb verbleven op als onderdeel van het team, het helpen om te beoordelen, bewerken en opmaken van de artikelen. Maar ik heb ook al in staat om te voldoen aan de wens sprak ik bij de lancering van het nieuwe ontwerp:

Ik ben een grote voorstander van iteratie en het niet behandelen van een website als ze klaar. Ik hoop dat wat er is uitgebracht dit jaar kan fungeren als een foundation, en dat het ontwerp zal evolueren in de komende jaren.

In de tussenliggende jaren, als instrumenten verbeterd en best practices zijn geworden, ik heb het aangepast in het ontwerp en refactoring van de code, en ontwikkelde een component bibliotheek in het proces.

De 24 manieren home pagina

Een Focus op Toegankelijkheid

Dit jaar heb ik geluisterd naar mensen als Laura Kalbag praten over de toegankelijkheid in termen van universal design, en gevolgd blogs zoals Heydon Pickering is Inclusief Onderdelen, die betrekking heeft op het ontwerp en de uitvoering van de gemeenschappelijke interactie patronen met een inclusieve denken. Alle van een plotselinge, het netelige onderwerp van de toegankelijkheid heeft het gevoel meer laagdrempelig en minder dogmatisch.

Met al deze kennis verteerd, ik was erop gebrand om te zien hoe de 24 manieren zouden doen als ze onder de microscoop. In dit artikel zal ik in vijf gebieden waar was ik in staat om verbeteringen aan te brengen:

  • Pagina structuur
  • De etikettering van de elementen
  • Toetsenbord navigatie
  • Auditieve ervaring
  • Algemene bruikbaarheid

Voordat ik begin met een opmerking van dank. Na het maken van een eerste reeks van veranderingen, vroeg ik mijn vriend en toegankelijkheid expert Francis Storr om te beoordelen voor mijn werk. Hij ontdekt een aantal bijkomende problemen, deels als gevolg van zijn ervaring op dit gebied, maar ook van het testen van de site met een assortiment van verschillende hulpprogramma ‘ s.

Heroverweging Pagina Structuur

Het oorspronkelijke ontwerp was aangenomen een mobile-first benadering. De navigatie was deprioritized en geplaatst in de richting van de onderkant van de pagina. Om ervoor te zorgen dat het kan worden geopend vanaf de top van de pagina in niet-JavaScript-scenario ‘ s, heb ik er ook een gaan skip to navigation link. Wanneer JavaScript beschikbaar was, is deze link werd gecoöpteerd te onthullen van een navigatie-lade, die zou slide-in vanaf de boven-of rechterkant, afhankelijk van de breedte van de viewport. Dit resulteerde in de volgende pagina structuur:

<header class=”c-banner”>…</header>
<a class= ‘c-menu” href=”#menu”>Spring naar menu</a>
<main class=”c-main”>…</main>
<nav class=”c-navigatie” id=”menu”>
<div class=”c-traverse-nav”>…</div>
<div class=”c-navigatie__lade”/>…</div>
</nav>
<footer class=”c-contentinfo”>…</footer>

Achteraf was dit problematisch zijn in een aantal manieren:

  • De menu knop (.c-menu) was niet naast het element dat wordt gecontroleerd (c-navigatie-lade). Het verplaatsen gaat het om de pagina als dit kan verwarrend zijn, vooral als het niet goed gemanaged.
  • Alle navigatie op de site is gegroepeerd, hoewel elke set van links diende een ander doel.
  • De lade gedrag gebruikt op het hebben van een link gedragen als een knop. Echter, de eerste regel van het ARIA-staten:

    Als u kunt gebruik maken van een native HTML-element of attribuut met de semantiek en gedrag u nodig heeft al in, in plaats van re-purposing een element en het toevoegen van een ARIA rol, toestand of eigenschap om het toegankelijk te maken, dan doen

    Vorig jaar heb ik bijgewerkt de JavaScript-code, zodat deze koppeling zou worden vervangen door een knop, maar deze complexiteit is een hint dat mijn oorspronkelijke oplossing is sub-optimaal.

Hier is de structuur kwam ik op vandaag:

<header class=”c-banner”>

<a class=”c-banner__overslaan” href=”#main”>Overslaan en naar de inhoud</a>
</header>
<div class= ‘c-menu”>
<button class= ‘c-menu__knop”>…</button>
<div class= ‘c-menu__lade”>…</div>
</div>
<main class=”c-main” id=”main”>…</main>
<nav class=”c-traverse-nav”>…</nav>
<footer class=”c-contentinfo”>…</footer>

Het verplaatsen van de navigatie naar de top van de pagina bedoeld de knop en lade werden nu naast elkaar. De knop menu is niet langer twee gezichten; het is en zal altijd een knop.

Een nadeel van deze aanpak is dat de navigatie kan worden gehoord, iedere keer dat u naar een nieuwe pagina. Nogmaals, we kunnen gebruik maken van een skip-link, maar dit keer één die verwijst naar de inhoud blokkeren (#main). Dan verberg deze focussen element van bepaalde gebruikers, wordt dit zichtbaar op focus.

Deze structuur kan minder ideologisch zuiver, maar het is veel pragmatischer. Dit werd een terugkerend thema. Inderdaad, het feit dat alle hoop van de HTML5-outline-algoritme ooit wordt ondersteund door browsers, ik stopte met het gebruik van h1 voor koppen en volgde de aanbeveling die kop gelederen moet worden gebruikt voor het vervoer van document structuur voor in de plaats.

Het Verbeteren Van De Navigatie Via Het Toetsenbord

Als de meest interactieve onderdeel op de website, het menu was verrassend focus van mijn review. Het ontwerp bepaalt dat de navigatie lade moet gedragen als een dialoog, een interface patroon dat brengt een aantal veronderstellingen. Deze worden in detail beschreven in eBay ‘ s GEDACHTEN patroon, maar in wezen een dialoog trekt de aandacht weg van de andere elementen op de pagina en is modaal; alleen elementen binnen het kan worden bediend terwijl het is geopend.

Ik had eerder geplaveide samen verschillende bits van JavaScript te hanteren gericht (cobbling die op verschillende punten en produceerde de vreemde bug zoals het niet te tekenen focus naar het eerste element in de dialoog), maar had verzuimd om aan te geven in het menu op de rol. Met vast deze problemen (het toevoegen van rol=’dialoog’ als het menu is geopend), Francis gewezen dat scherm konden lezers nog steeds toegang tot links buiten het dialoogvenster werd geopend. In macOS VoiceOver bijvoorbeeld, druk op CTRL + OPT + CMD + L om te navigeren links in het menu, zou in feite kondigen iedere link op de pagina.

De oplossing werd gevonden in het teken van alles buiten het dialoogvenster “inert”. Rob Dodson beschrijft dit in meer detail in zijn video Toegankelijk Modale Dialoogvensters. De uitvoering van deze kan een beetje onhandig, maar een voorstel tot invoering van een fysiologisch kenmerk zou dit makkelijker te beheren. In de tussentijd voorziet het voorstel in een polyfill dus u kunt deze functie gebruiken vandaag.

Ik heb ontdekt dat door te denken over een interface in termen van het gemeenschappelijk interactie patronen, en hoe ze moeten werken om op grote schaal worden begrepen, en heeft me geholpen om te voorkomen dat de complexiteit en het schrijven van meer robuuste code. In feite, een stap in de wereld van de toegankelijkheid heeft ontdekt een schat van nuttige bronnen met goed geschreven JavaScript voorbeelden in overvloed. Gezien mijn moeilijke relatie met de web programmeertaal, deze zijn van onschatbare waarde te zijn.

Goed Etiketteringselementen

Een goede hoeveelheid van de toegankelijkheid gaat om etikettering dingen die vertrouwen op visuele verschijning alleen om betekenis over te brengen. Net als de alt-attribuut stelt ons in staat om te beschrijven beelden, aria-label (en haar betrekkingen) verlenging van deze mogelijkheid om andere elementen.

Navigatie component die gebruikers in staat stelt om te bewegen tussen de artikelen in een serie.

Hier is de markup ik was het gebruik in de navigatie-element dat gebruikers in staat stelt om door de vorige en de volgende artikelen in een serie:

<div class=”c-traverse-nav”>
<a rel=”prev” href=”/2016/we-moeten-om-te-praten-over-technische-schuld/”
data-volgorde title=”We Moeten Praten Over Technische Schuld”>
<svg width=”20″ height=”20″ viewBox=”0 0 200 200″ role=”img”>
<path d=”M50 100l85 85 7-7-78-78 78-78-7-7″/>
</svg>
<span class=”u-hidden”>Vorige artikel</span>
</een>

<a rel=”next” href=”/2016/what-the-heck-is-inclusive-design/”
data-volgorde title=”Wat de Heck Is Inclusief Design?”>
<span class=”u-hidden”>artikel</span>
<svg width=”20″ height=”20″ viewBox=”0 0 200 200″ role=”img”>
<path d=”M150 100l-85 85-7-7 78-78-78-78 7-7″/>
</svg>
</een>
</div>

Terwijl ik had verschaft de inhoud van de tekst voor deze links, wordt dit onderdeel nog een aantal zaken:

  • Geen indicatie is gegeven op de rol van deze links spelen en hun relatie tot elkaar.
  • Met behulp van role=’img’ op de SVG pictogrammen, maar het niet verstrekken van een toegankelijk namen, was vergelijkbaar met inbegrip van afbeeldingen zonder alt-attributen.
  • Nuttige informatie, in dit geval de titel van het vorige en volgende artikel, was verborgen in een data – attribuut. Dit kenmerk werd gebruikt in de stylesheet toevoegen van inhoud die wordt weergegeven in geanimeerde ‘flappen’ die worden weergegeven op een zweeftekst kan oproepen:

.c-traverse-nav a[rel= ” prev]:hover::after {
inhoud: ‘Vorige: A’ attr(gegevens-de volgorde van titel);
}

.c-traverse-nav a[rel=next]:hover::after {
inhoud: ‘het Volgende: ‘ attr(gegevens-de volgorde van titel);
}

Zinvolle inhoud in CSS? Dat moeten zijn van een rode vlag. Ik herziene dit onderdeel als volgt:

<nav class=”c-traverse-nav” aria-label=”Artikelen”>
<a rel=”prev” href=”/2016/what-the-heck-is-inclusive-design/”
aria-label=”Vorige: We Moeten Praten Over Technische Schuld”>
<svg width=”20″ height=”20″ viewBox=”0 0 200 200″ focussen=”false” aria-hidden=”true”>
<path d=”M50 100l85 85 7-7-78-78 78-78-7-7″/>
</svg>
</een>

<a rel=”next” href=”/2016/what-the-heck-is-inclusive-design/”
aria-label=”Volgende: Wat de Heck Is Inclusief Design?”>
<svg width=”20″ height=”20″ viewBox=”0 0 200 200″ focussen=”false” aria-hidden=”true”>
<path d=”M150 100l-85 85-7-7 78-78-78-78 7-7″/>
</svg>
</een>
</nav>

Het eerste wat ik deed was geven deze links een label. Ik ben oorspronkelijk kies de Artikelen navigatie. Echter, bij het testen van VoiceOver zou aankondigen: navigatie, Artikelen navigatie. Als het nav element beschrijft al de rol, we moeten alleen zorgen voor extra informatie over de soort van navigatie dit is.

In de tweede plaats, op advies van Francis, ik toegevoegd focussen=’false’ om alle inline SVG-markup. Dit is te wijten aan een bug in IE11 waar SVGs zijn toetsenbord te focussen standaard.

Met betrekking tot de etikettering van de SVG-iconen, had ik twee keuzes. Ik kon beweeg de verborgen de inhoud van de tekst om deze pictogrammen met aria-label, of het verwijderen van de toegankelijkheid boom in zijn geheel met behulp van het aria-hidden. Bij het overwegen van de tweede optie, besefte ik dat ik kon samenvoegen van de verborgen tekst met die in de data – attribuut, en het gebruik van deze gecombineerde informatie binnen een aria-label attribuut. Alle van een plotselinge, mijn CSS werd het veel eenvoudiger:

.c-traverse-nav a:hover::after {
inhoud: attr(aria-label);
}

Toegankelijk markup is handig markup.

Gezien de Auditieve Ervaring

Het navigeren van de site het gebruik van een screenreader leiden mij tot het maken van een paar andere kleine veranderingen. Bijvoorbeeld, een paar links op de site ook een pijl die naar rechts wijst, een visuele bloeien gemaakt met de volgende CSS:

.c-verder::after {
inhoud: ‘203 BIS’; /* Single die naar Rechts Wijst Hoek aanhalingsteken */
}

Echter, scherm-lezers meestal kondigen generated content. Wanneer deze links zijn lezen, u wilt horen onzin zoals dit:

link, meer artikelen van drew één naar rechts wijst hoek aanhalingsteken.

Het toevoegen van spreken: niemand had geen effect (CSS auditieve eigenschappen hebben weinig ondersteuning). Echter, ik kon een soortgelijke maken de pijl met behulp van CSS grenzen:

.c-verder::after {
display: inline-block;
vertical-align: middle;
hoogte: 0.375 em;
breedte: 0.375 em;
grens: 0.1875 em solid;
border-color: currentColor currentColor transparant transparant;
transform: rotate(45deg);
inhoud: “;
}

Verder links vóór en na de verbeteringen. Hoewel ze er hetzelfde uitzien, het herziene ontwerp klinkt veel beter.

Ik heb ook verbeteringen aangebracht aan de styling van de auteur in artikel samenvattingen. Oorspronkelijk werden deze onderscheiden zich van de rest van het fragment door styling hen als hoofdletters tekst. Francis op gewezen dat sommige schermlezers spreuk uit hoofdletters (ongeacht of ze voorkomen in de HTML of gewijzigd door CSS) als ze niet spreuk een bekend woord. Bijvoorbeeld VoiceOver en NVDA hebben moeite met Chris Coyier naam, dus zijn naam zou worden uitgesproken als Chris C-O-Y-I-E-R. De eenvoudige oplossing was om te onderscheiden namen met verschillende tekst voor in de plaats.

Als ik eerlijk ben, heb ik een beetje arrogant in het verleden, denken dat door het gebruik van semantische opmaak en progressive enhancement, ik hoef niet al te veel zorgen over de toegankelijkheid. Tijdens het gebruik van de juiste elementen, en het overwegen van een interface niet alleen in de zichtbare vorm is belangrijk, dit is het absolute minimum. Een goed begrip van de verschillende ondersteunende technologieën, en de bereidheid om te testen met hen, is net zo belangrijk.

Herziening Van De Algemene Bruikbaarheid

Het denken over toegankelijkheid leidde tot mij het verbeteren van de algehele usability, ook.

Voor dit jaar ingesteld van de artikelen, hebben we niet langer de link naar de auteur websites van artikel fragmenten. Dit historisch overblijfsel was slecht opgelost eerder; als je toevallig te klikken op de naam van de auteur zou u worden genomen om hun website, niet het artikel zoals je zou verwachten. We geven ook commentaar telt die gekoppeld waren aan de commentaar op de artikel pagina (die zelf gekoppeld aan een aparte pagina met opmerkingen). Waanzin!

Nu, elk artikel heeft een link naar het artikel. Een startpagina die ooit betrokken tab-toets door middel van een 24×3 links, is nu minder lawaai en veel gemakkelijker om te navigeren voor iedereen.

Andere verfijningen opgenomen waarborgen van de site is responsive, in termen van hoogte als in de breedte, zodat de navigatie-menu kan worden ontslagen wanneer u op de buitenwereld, en een beoordeling van de algehele prestaties. Deze kunnen niet worden beschouwd als toegankelijkheid verbeteringen, maar ik ben niet zo zeker van. Om te suggereren dat dit zou zijn om te denken dat toegankelijkheid is een geheel aparte zorg. In feite, het maken van veranderingen die ten goede komen aan één set van de gebruikers zal meestal profiteren.

Het creëren van iets nieuws blijft altijd trekken de aandacht en bewondering, maar er is een onder-gevierd adel in het verbeteren van wat er al bestaat. Hoewel niet alle wijzigingen kunnen worden visuele, ze kunnen net zoveel impact hebben. Ik weet dat, hadden we besloten om een redesign van de site dit jaar, veel van deze verbeteringen niet hebben plaatsgevonden. Hopelijk dit overzicht zal u aanmoedigen om te kijken naar uw eigen projecten en na te denken over soortgelijke veranderingen die je zou kunnen maken.

Het hebben van een groeiend bewustzijn van de problemen, en het uitbreiden van uw kennis van de beschikbare hulpmiddelen, is een essentiële vereiste voor het werken op het web. Echter, niet houden van die kennis gespaard voor de toekomst; als je kunt, ga dan terug en bevestig uw oudere projecten.