I had the great opportunity to represent a11y group of MeetMagento Association at Funka accessibility days. You can read Part 1 of this post, which focuses on EU policy and directives and the general conference track, while here I will be discussing some more technical aspects of accessibility.
Guidelines and the Silver Project
If you have any interest in web accessibility I’m sure you’re aware of the Web Content Accessibility Guidelines (WCAG) created by World Wide Web Consortium (W3C). W3C does an amazing work in the field of a11y and Shadi Abou-Zahra from W3C did an interesting recap to show us how amazing it really is.
W3C is an international, vendor-neutral consortium develops royalty-free web standards like HTML, CSS, XML, SVG, SMIL etc. They take care of accessibility support in digital technologies by creating and evolving guidelines for a11y implementation, coordinating theme and set as a standard. (WCAG 2.0 on the AA level is currently referenced in laws and policies internationally). They develop solution for new technologies used in digital media and make tutorials, tips, checklists to provide educational support.
The rapid technological developments in web bring real challenges for W3C. Current guidelines don’t cover all needs of mobile and tactile devices which are now widely used. Interesting fields such as IoT, VR, AR, AI, Automative Systems also need to be addressed, and W3C has already started working on this in the “Silver” project, whose goal is to provide a major revision to the WCAG standard, as part of its update to incorporate requirements for user agents and authoring tools as needed. The new guidelines should cover more digital technologies, should be more inclusive, understand and easier to use. (More information: Process of Designing Silver).
The “Silver” project will require a lot of time and work, but in near future we will have new version of WCAG – 2.1. Scheduled for final completion in June 2018, it should be fully backwards compatible with WCAG 2.0 and currently includes 17 new Success Criteria focus the most on improvements for people with cognitive and learning disabilities, low vision, and on accessibility in mobile apps.
WCAG 2.1 in detail
Henrik Juhlin and Christer Janzon from Funka presented what are new rules of WCAG 2.1 and how should we deal with them in code. So what’s new?
For the A level, we have to pay attention to key shortcuts – they should be active only when elements are focused and should contain only letters, numbers or symbols. We should take care that labels so have the same beginning as a name (name attribute or main text) and are applied to all displayed graphic elements, and ensure any web animations are able to be interrupted by user action.
Level AA requires full support for portrait and landscape orientations, and full responsiveness with no additional scroll on small screens. Moreover, we have to take care of displayed text on website – it cannot be cut or hidden and require specified spacing – between words (0.16 x font size), letters (0.12 x font size) and lines (1.5 x font size). We will have to work on focus management to make it really usable – every hover element should react on focus too and be operable with both keyboard and mouse, and folded elements cannot disappear by itself. Every change on the website should be managed with aria-live attribute to be available for assistive technologies. Furthermore, the contrast of non text elements (user interface components and graphic object) should has ratio of at least 3:1 and autofill attribute should be added to form fields.
You can find all the new rules here.
Accessible emails
Let’s get a closer look at a great talk of Mark Robbins about the important issue of accessibility in emails. An email has approx 15 000 potential renderings (2 Email Service Providers x 15 operating systems x 50 email clients x 5 screen sizes x 2 image states), and is much more complex than a website, so it doesn’t follow exactly the same rules.
Normally, we use tables for displaying email content. Table are generally not very good for assistive technologies and on the web we use tables for specific data presentation; so why should we use them in emails? Well, Outlook desktop and Windows mail don’t use a HTML & CSS rendering engine. Instead, they use Microsoft Word, so we are obliged to use a table as the easiest way to wrap our content correctly. It’s not a perfect solution for screen readers, but adding role=”presentation” can fix it.
Unfortunately, some email clients actively remove roles and ARIA attributes (Outlook.com, Outlook 365, AOL, Yahoo, GMX, Web.de), so we have to make some workarounds to display content properly:
More code tips for emails
In text elements, don’t use <span>, <div> or <td> instead of text tags <p> and add an inline margins because Yahoo and Outlook set default margin of <h> and <p> tags to 0. When using list elements (<ul>, <ol>) and adding inline styles, Word will convert it to text elements and break the layout, unless you also add:
on the list item element :)
Developers often use images to display more visually complex content in emails. In this approach we should remember the alt attribute. Use this tag to describe the image, and copy any text in the image into the alt. Don’t repeat yourself and don’t be afraid of a blank alt. A lot of email clients don’t download the image if the user doesn’t trigger the action, but the alt attribute will still communicate the image’s message; this could influence your email conversion rates.
There’s not much user interaction in email content besides links. Dynamic content like hiding and checkboxes (implemented with JavaScript on Web) is a near-impossible challenge. But Mark Robbins show us how we can use CSS in email to implement some interesting dynamic feature to interact with email user. Check out this example made by Mark Robbins, if you are interested:
https://codepen.io/M_J_Robbins/pen/aVJBXd
And here is a list of articles about making emails accessible.
Web components in use
In emails we can’t use JavaScript, but on the web it’s gaining popularity for building user interfaces, especially in libs and frameworks like React, Angular, Vue.js or Web Components.
Justin Stockton from The Paciello Group discussed how to work with components, and make them reusable and accessible. When developing bigger and more complex interfaces, it’s good to have a group of components we can reuse for different purpose – e.g one component to add, edit or display user data, and another for products list on different pages (catalog, user’s dashboard etc). Sometimes views can divert one from another; so should we rebuild this component by adding a new feature or create a new component for the added functionality.
It is difficult while working with components and the answer is not obvious because each case is different. Justin Stockton gave us some tips how we can manage this work:
Keep some principal rules:
- DRY – Don’t Repeat Yourself
- CRUD – Create, Read, Update, Delete
- KISS – Keep It Simple, Stupid
- BDUF – Big Design Up Front
and remember them when building components.
Reusing components is only helpful if you spend time on architecting the solution, document it well and keep it simple and focused. Before starting to code, ask yourself twice if you are using the right component. Let’s make it accessible for all developers too! ;)
It may seem like a11y implementation can complicate our web components a lot, but if we consider a11y as an integrate feature of component and plan it well, we will learn to adapt to them. We just have to learn how to implement it simply and effectively.
It’s also good to maintain all features of our component by writing a unit test for each. With unit tests, even if another developer working on the code would like to remove some part which they don’t understand (e.g accessibility feature, focus managements etc), the test would fail showing an error. It is also a “form” of code documentation.
If you want to dive deeper in this topic, I recommend to take a look on Justin Stockton’s presentation – there are some interesting use cases and code sample in Vue.js. Very inspiring!
Mobile Accessibility
In 2017 mobile traffic made up over 50% of online traffic according to statista.com. Moreover, we use our phone on a daily basis communicate (phone, chats, SMS) and to organize our private and work life. Ensuring mobile devices available for people with disabilities or impairments is crucial.
Sommer Panage, iOS & accessibility developer showed us the essential factors to consider when developing an accessibly iOS app:
- Fonts format
- Color setting and contrast
- Screen readers
- Captioning
- Switch system
With touch and smaller screens and different input modalities, a11y implementation is different to that of web, but luckily, iOS contains a lot of features available by default in API so iOS developers should become aware of and start using those features.
Sommer did a great Case Study demonstrating how to implement a11y feature step by step using UI or code commands. I really recommend to read the slides from the talk, and if you are an iOS developer – there’s a lot of practical knowledge and tips. I found also a great presentation by Sommer about a11y, check it out!
Certification in Accessibility
I couldn’t leave out the announcements about certification in web accessibility fields. Frida Sandberg and Samantha Evans from IAAP introduced us to an interesting and quite new opportunity in web accessibility area. The IAAP (International Association of Accessibility Professionals) is a non-profit, membership-based organization for individuals and organizations that focussed on accessibility. The objective of IAAP is to help accessibility professionals develop and advance their careers and to help organizations integrate accessibility into their products and infrastructure. Currently, IAAP has 1 421 members where 80 are organizations or companies and has representation from 42 countries.
The IAAP started to work on its certification program to define what accessibility professionals are expected to know and increase the quality and consistency of their work.
There are 3 possible certifications:
- IAAP Certified Professional in Accessibility Core Competencies (CPACC) – focused on disabilities, assistive technologies, design and laws on accessibility.
- Web Accessibility Specialist (WAS) – focused on WCAG and destined to developers.
- Certified Professional in Web Accessibility (CPWA) – earned by individuals who successfully pass both others (CPACC and WAS).
Those exams are not a piece of cake. They are complex and quite difficult, prepared according to the latest guidelines. Moreover, it is the IAAP who, after surveying your a11y work and activities, decide if you can take a certification test.
If you are interested in this area and you would like to be web accessibility expert, check more info on: http://www.accessibilityassociation.org/certification
Other conference features
Funka Accessibility Days is an amazing place to share knowledge on a11y with developers, designers and people who implement a11y features in their daily work. There was a great exhibition with live demos and trials of accessibility solutions; screen readers, text to speech apps, and even RPG games where you cannot see the screen.
For me, the most interesting was a VR experience where using 3D glasses you can simulate being in a business meeting like a person with different cognitive impairments. Stimuli considered as “normal” for most people were overplayed and after 5 min of distracting lights, objects and voices, I wasn’t able to work out what the meeting was about.
A great visual recap of the talks can be found in the Funka graphic recordings. Each presentation was summarized on sketch-style image like this (from Mark Robbins talks about accessibility in emails):
Mark Robbins – Graphic Recording at Funka Accessibility Days
You can find the other graphic recordings here:
I came out of Funka really inspired and with much to learn about the field of web accessibility, and a strong motivation to find new solutions. It was a completely new experience for me, and I’m deeply appreciative to the many communities of great people who care about a11y.
Links:
Slides from Funka Accessibility Days 2018
The process of designing Project Silver
Web Content Acccessibility Guidelines (WCAG) 2.1
