Sito accessibile

Accessibilità significa accesso in generale. L’accessibilità nel web design significa creare pagine Web che tutti possono utilizzare, indipendentemente dalla disabilità o da esigenze particolari, e questa scelta consente a tutti di utilizzare e trarre vantaggio da tutto ciò che è nel loro ambiente.

Tratto da Wikipedia:

L’accessibilità si riferisce alla progettazione di prodotti, dispositivi, servizi o ambienti per persone con disabilità. Il concetto di design accessibile garantisce sia “accesso diretto” (cioè non assistito) che “accesso indiretto” che significa compatibilità con la tecnologia assistiva di una persona (ad esempio, lettori di schermo di computer).

In WordPress, c’è una missione per rendere WordPress accessibile a tutti, compreso il miliardo di persone con disabilità. E i progressi regolari dimostrano che questa missione sarà raggiunta nel prossimo futuro.

Dopo aver sentito così tanto sull’accessibilità in WordPress, ho voluto provarlo anche nel mio tema. Così ho deciso di rendere accessibile il mio tema libero Simple Life. Era una cosa nuova e non sapevo nulla sul rendere accessibile il tema. Dopo aver trascorso alcune ore a studiare gli elementi chiave in Accessibilità, ho iniziato a modificare il tema. Onestamente, ci sono volute alcune iterazioni per rendere finalmente accessibile il mio tema, ma ho imparato molto nel processo e ne sono felice. Voglio condividere alcuni punti importanti durante lo sviluppo di temi o plug-in accessibili per WordPress.

I punti li ho lasciati in inglese, la lingua che consente ai programmatori di tutto il mondo di condividere il loro sapere

  • Headings: You should always use a reasonable HTML heading structure — including the use of heading elements for page sub-sections. Heading markup must not be used for presentational purposes. For example, there must be one and only one h1 tag in a page. Heading should not skip levels. h1 should be followed by h2, not h3.
  • Keyboard Navigation: Site elements like links, buttons, form fields, dropdown menus, etc should be able for navigation using keyboard. This will specifically benefit keyboard-dependent navigators or users of alternative input devices who are sighted. When any link is focused it should be visually distinctive. Tab order should be natural. Also you should not use ‘tabindex’ attribute. Tab and Shift+Tab key should work as expected.
  • Controls: If you have any feature that behave as buttons or links then you must use <button>, <input>, or <a> elements, to ensure native keyboard accessibility and interaction with screen reader. Also all controls must also have machine-readable text to indicate the nature of the control.
  • Forms: All forms in your theme of plugin must have appropriate field labels and all content within form tags need to be explicitly associated to a form control. Post-submission responses (errors or confirmations) must be perceivable. Each field inputs should be explicitly associated with <label> elements.
  • Skip Links: This is specially required for themes. Themes must include a mechanism that enables users to navigate directly to content or navigation on entering any given page. These links may be positioned off screen initially but must be available to screen reader users and must be visible on focus for sighted keyboard navigators. Skip link should be first focusable link in the page. It should be visible when keyboard focus moves to the link and this link should move focus to the main content area of the page when activated.
  • Link Text: Generally ‘read more’ links are used in themes. But there are more things those needs to be considered keeping such links. Links must avoid repetitive non-contextual text strings such as ‘read more’ and should make sense if taken out of context. Bare urls must not be used as links. Supporting text may use a screen reader class to hide text visually.
  • ARIA Landmark Roles: ARIA landmarks are attributes you can add to elements in your page to define areas like the main content or a navigation region. It provide method for screen readers to navigate to the large structural regions of a site. All content on your site must be wrapped in at least one landmark role. Any content not wrapped in a landmark role is ‘orphaned’, and may not be found by screen reader users. You can find more about ARIA landmarks and example here. Using ARIA landmarks to identify regions of a page
  • Contrasts: You must ensure that all background/foreground color contrasts for plain content text are within the level AA contrast ratio (4.5:1) specified in the Web Content Accessibility Guidelines (WCAG) 2.0 for color luminosity. Background/foreground color contrast also applies to change of state (:focus or :hover) if there is no additional indicator of :focus or :hover, such as a text decoration change. You can find some online tools to check contrasts.
  • Images: Theme or plugins may have implemented images. Decorative images must be included using CSS. Where you add images to template markup or provide a method for end users to add images, you must incorporate an appropriate alt attribute or the means for an end user to provide one. Every ‘img’ tag must have ‘alt’ attribute. If you have used any icon fonts like Font Awesome of Genericons, then you must implement ‘aria-hidden’ for such tags.
  • Media: Media resources must NOT auto start or change without user action as a default configuration. This includes resources such as audio, video, or image/content sliders and carousels.

Some useful links:
Web designer Silvia Lupanohttps://www.linkedin.com/in/silvialupano Italia
Programmazione e realizzazione template responsive accessibile Nilambarhttps://nilambar.net/ – Nepal

Want to join WordPress Accessibility Team?

Developing Accessibility Ready theme for wordpress.org?

Image source: Linkedin