In the end of April we had the first Offline Camp in Europe! It was my first "unconference" and I was a bit curious about it in the beginning. First of all, the participants propose discussion panels and, after voting, group discussions are created about a certain topic: one of those was accessibility! There are also passion talks, which are 5 to 10 minute talks about something you want to share (could be technical or non-technical). I recommend you to take a look at "What is Accessibility?" passion talk if you haven't seen one. The registrations for the camp are limited to 45 (?) participants, which helps everyone get to know each other and the discussions to be more proactive.
TODO: confirm 45 participants?
I decided to attend to "A11Y" discussion because I barely knew anything about accessibility. Usually we don't think that much about A11Y as we should.
The session started with us talking about how can we relate accessibility with offline first and how it can change people's lives. We identified different types of disability such as cognitive, vision, motor, an so on. The discussion was mainly around our concerns regarding web (the majority of the people in the room were a web developer) and what we do when creating Single Page Applications (SPA).
We shared some examples and common problems, namely:
- Routing;
- Semantic web (e.g. the [in]correct usage of hierarchical headings);
- Using a select box (versus an input with ARIA attributes);
- Forms;
- Tricks using tabIndex;
- Change transitions (e.g. animations) in the page;
- Always giving feedback from actions;
- ...
These issues do not help to make our web more accessible. If you're a JavaScript developer, think twice before using onMouseOver events when creating on-hover drop-down menus! These actions should be device independent (both mouse and keyboard should be available to perform an action).
There's also some standards that must be followed and that people create expectations about. For instance, an HTML reference must link to "Contact us" and never to "You can contact us" (or similar). The last options are less intuitive and will not be in the same order if people decide to ask screen readers to read alphabetically. Please take into consideration that the alphabetic ordering only applies to menus and lists of links, not links that form part of the document body. Moreover, every action should have an effect: when the user clicks on something, the page should react and feedback needs to be provided.
If you're like me, you probably heard about ARIA attributes before. Recently I found a super interesting and enlightening blogpost that has actual answers about what people with disabilities think about A11Y. This list made me feel really bad about the content we produce. It's a quick jump to start using ARIA correctly.
[TO REMOVE?!] However, it's really difficult to have a website that is fully accessible because different people with different disabilities have different requirements. For example, in the mentioned blogpost is pointed out that color contrast and photo backgrounds are "a major problem". We even do that in OfflineCamp website.
Its quite common for me now to go to a new website and press Tab key to see if they have the "Skip Navigation" link (which defaults to display: none if Tab is not pressed):
This is really useful for someone that just wants to find the content because you can go directly to it, ignoring header and other fancy stuff that we have around our websites. This is progressive enhancement at its best! If you didn't know about that, please learn more about Skip Navigation trick. I learned a lot inside and after this session. Always be curious!
[TODO:: maybe find other example?] One interesting point of our group discussion was how should we alert users about a change in the page. Imagine that your user is reading your newspaper and a really important new appeared in the website, such as a huge fire in a specific location. For a person that can see it will be visible and the person gets notified. However, for blind people we need to decide when to show that information: should we show that instantly? or after the current sentence being finished? or not be shown at all? It really depends on the priority, and the user screen reader also has some settings for it (checkout aria-live attribute).
Our conclusion from the session was that accessibility is not specifically an offline-first problem, but we can help with that. We discussed how Service Workers can help by intercepting fetch requests and returning the relevant content. Moreover, it was discussed how some web elements such as forms can be accessible to everyone with correct attributes and how we can make them offline. To sum up, we believe that developers and people in general need education about A11Y and we should push and promote it, because it is not that difficult to remove some of the barriers for people with disabilities.
Install an extension. Start using tab and shift + tab to navigate the web. You will find it more difficult than expected if you never tried it. I recommend trying NoCoffe extension for Chrome, which simulate sight issues such as Blur or Cloudiness:
You can also give a chance to VoiceOver on MacOS, JAWS on Windows or some other screen reader (you may even have issues if the settings are for a particular language and the website is not defining any!). The list of problems that may arise is incredible.
We have all these tools available right now, but the real tests are with real users. At the camp session, we had some people sharing successful stories about the UK government best practices on this inviting people with disabilities to actively participate on the development process.
TODO:: confirm with Nick if I can share this!
-
Cool list of ARIA examples;
-
Specs from W3C for ARIA. I found the issues quite interesting;
-
How The Guardian is educating developers about Accessibility;
-
UK Government Dos and don'ts on designing for accessibility was also one of my favorite articles, that summarizes really well their findings;
-
Check out accessibility dev tools by Google;
-
Awesome-A11Y has a list of resources to learn about A11Y;
-
Pa11y has a set of tools for designers and developers to make the web more accessible;
-
AxE quite awesome set of tools (chrome extension + various flavours of CLI and integrations)
-
Do you use React.js? Me too! Few days ago some people from the community published a list of standards and guidelines about accessibility.
I left the group discussion empowered to search about accessibility and what I can do as a developer to educate and help. This was the trigger for me and I got motivated to read some articles and watch some talks about accessibility.
In the end of our session, we talked a bit on twitter about these issues. Check out that quick discussion:
TODO:: Include tweet: https://twitter.com/MylesBorins/status/858695075370590208
Recently a friend provoked me by sharing a tweet about Progressive Web Apps (PWAs) and A11Y:
TODO:: Include tweet: https://twitter.com/stevefaulkner/status/877061641438990336
I really don't think it's true and our group session is consistent with that opinion. If we create truly accessible PWAs if we educate our developers. We know that the challenge is ambitious and augmented by different disabilities, but we are thinking about the future and how can we help and change that, in order to create a better web.