2023/Nuremberg/a11y
Accessible web was a session at IndieWebCamp Nuremberg 2023.
Notes archived from: a11y
Participants
Praticipants:
- Ryan (moderator)
- Jeremy K.
- Sebastian
- Sonja
- Toh
- Joschi
- Rony ?
- ?
Notes
Most of the sites (96%) are not accessibly.
Some of the accessibility problems are on different level - UK have a framework for this. For example, for the screen readers, the headers are more important then some other. Which accessibility problems are actually effecting users? Prioritise the actual user complains.
Doing things like labels on the forms can be a long step up for the screen readers users. The list is actually short.
How much control, does the user have over the experience? Can they change the font - what web does by default? Web tired to be accessible to default.
It is hard for people without disabilities to understand the people. Example, how to stop pointing to thing 'Look over there', to the blind people. Sometimes this can take months or years.
Sometimes content can be an accessibility problem. Like the button - click on the right corner button.
Simple sites are easier to keep accessible.
Who is responsible for the experience? Let people do whatever they want - change the colours, fonts,... instead of providing these options.
For people with motor disabilities, it is important to check how responsive are the responsive sites - for example the embedded video - is it responsive.
Some of the airline companies sites are really not accessibly - but even the service conversation does not help. Why there is no normal forms for booking and getting any assistance for checking the data. So people are forced to bomb people on social media and hope for response.
The free text fields could be a solution. From the usability perspective it is easy. From the technical perspective, it is dangerous. They can also be used to keep track of data, that should not be tracked - like people are drinking. Also, the bug companies are not reading the free text field.
This is not an excuse to not do anything.
It is a job of a programmer, that pushes back on this?
There is the difference between the technical accessibility and the user experience accessibility. The later is not covered by standards, because it is not automatically testable. They are the UX question, since even if all the parts are accessible, the whole might not be.
Having too many options excludes the people with different cognitive functionality. Again, the UX problem. There is an intersection between usability and accessibility - usability is something that affects everything, and accessibility is about the groups of people.
WCAG does not have space for the opinion, it needs to be crispy clear. It only takes care of the needs of disability. It is not the whole story.
Is there an EU demands the support for people? There is no rule, that requires human interaction, which is what would be needed here.
About quarter of personal sites (anecdotes) are compliment. The most frequent problems are responsiveness and colour contrast and alternative text to images.
There are a couple of tools for testing sites. The example of this is axe dev tools or arc tools (Arc is better for beginners). Another way is to test site navigation with keyboard instead of a mouse. Or try it with a screen reader (Mac ships with VoiceOver, JAWS have the highest market share, ...). There are also style sheets, that show you the accessibility problems.
https://front-end.social/@matuzo/111297533122159227 β Manuel MatuzoviΔ asked a question about accessibility testing on Mastodon.
The problem with these tools is, that people without understanding of accessibility will not understand the results. So it is better to start with things like keyboard navigation and zoom testing.
We should be design for all people - accessibility affects us all.
The problems with websites are usually not the ones, that are seen with the glance - accessibility, security, privacy. If you do not see the problem, you don't find them important. We value more what we can immediately see.
The goals can be formalised into tasks, but sometimes this does not effect the goal in the way you want. Example: the people want the clean door, so they formalise to two whips every 2 hours - but it depends on the weather,...
There are different types of users. Not all of them are power users, and it is hard to make it more usable to everybody.
The biggest testing tool is users. Even though, there is a lot of variety in feedback, and also people can only tell you what people like them find problems. For example, the blind person can not tell you about the colour contrasts.
In some cases, it is import important to test the specific processes - like the main task of the tool. This need to be as accessible as possible. This can be more important, than the alternative text in the logo. This is pragmatic accessibility.
Unlike the normal accessibility testing, where you test everything. It is better to know the priority first, so people don't start with the useless details. So first test the critical path.
Progressive enhancement does something similar. The most important task needs to be as robust as possible. The rest is less important to make robust. On the blog, it might be reading the blog.
In some cases, the profiles of how users use the sites (accessibility personal) can be an alternative, if you do not have access to people to test with. UK provides these.
Accessibility is a process.