A small thing, and it opens HomeAssistant to the needs of people with disabilities. I am blind, with HomeAssistant, I use the NVDA screen reader on my Windows machine and Google TalkBack on Android. A lot of good has already been done regarding accessibility. This is one side of the coin. On the other hand, there are things to be improved in terms of accessibility.
As of today, only the first 3 things to improve:
Buttons - By setting the button (e.g. light), you can define the display of the name, icon, status. However, the status is not announced by the screen reader. NVDA and TalkBack can only read the button name. I don’t know if the button is on or off. The screen reader is not able to give me the correct information. Please pay more attention to the WCAG guidelines.
Installation - On installation, the problem is with the first form that the user has to fill out. Unfortunately, when using the NVDA screen reader, the task is difficult when entering the username or password. By typing 1 character, the focus point moves to the alert. You have to re-enter the edit field, enter the second character (focus to alert), enter the edit field and 3rd character, (focus to alert), enter the edit field and 4th character etc. Seriously, this is how it looks today. In the system, this is the only place where I encountered something like that. You can enter data, but it’s a damn frustrating task.
Structure and semantics - Is text that looks and acts like a heading marked as a real heading? Again, if you’re sighted, you can see big, bold text positioned over regular paragraph text and immediately know, “Oh, OK, that’s a heading.” But the screen reader doesn’t know that unless it’s semantically marked with heading tags, rather than just styled to look like big, bold text with CSS. Do section headings follow a hierarchical structure and do not skip any levels? Level 1 would be the top level, then level 2 would be a subsection of level 1, and so on. In HomeAssistant, the headline for the eye is, for example, Media Sources, History, Map etc. In the code, these headers should be marked as H1. Thanks to this, one key “h” (NVDA screen reader) is enough and I go to the right place.
So much for today. Please keep the WCAG guidelines under your pillow. Compliance with WCAG guidelines makes life much easier.
First, I have been working hard in my free time to make HA much more accessible so you are not alone and it is beginning to be taken more and more seriously by the project. On the general topic of WCAG compliance, please take a look at the GitHub accessibility project, where I am tracking and prioritizing issues. Also, just narrowing frontend issues with the accessibility label shows you the current open issues (plus I have some one line drafts in the project). Please don’t hesitate to comment on any of them or create new ones and mention me so I tag it right away.
Second, going through your 3 points:
Please be more specific about which buttons you are referring to so I can target the offending code. Open a detailed GitHub issue or let me know here and I’ll take a look.
Similarly, I need to know which specific form you are talking about along with steps to reproduce and browser/OS. I have not experienced anything like that using NVDA, and if it is really moving focus on each character input, that would affect everyone and not just screen reader users.
Here is the GitHub issue for heading tags. I’m going to start hacking more at this one so let me know which pages are most bothersome.
HomeAssistant a few years ago had quite big errors in terms of accessibility (compliance with WCAG guidelines). Years of project development allow us to notice a significant improvement in this regard. It is not perfect now, but it is much better than it was at the beginning of the project.
Coming back to my three points, the problems in terms of accessibility, I will try to describe the problem in more detail below. By the way, I will pay attention to the incorrect positioning of the tabs in the view. Cards that are read by a screen reader vertically (top to bottom column by column, not left to right row by row).
Go to the Lovelace desktop “Edit dashboard”.
Select the “Add card” option.
Enter “button” in the search engine and then select the “Button” tab that we want to add to the view.
Configure the card (enter the name of the button, select the entity, icon and select the display of the name, icon and status). Card code below:
We automatically go to the view. We already have a button on it (our new tab).
We use the button with any screen reader, eg NVDA, TalkBack etc.
The screen reader only reads the name of the “LIGHT” button. Click the button (turn the light on and off), the icon changes, the status changes, the light is working properly, the screen reader only reads the name of the “LIGHT” button. The button status (Enabled / Disabled) is not announced. And this is the crux of the problem.
Now the problem with the positioning of the cards.
Please duplicate the added button 5 times.
We now have 6 buttons in the view (2 rows of 3 buttons, 3 columns of 2 buttons).
Now go over the buttons with the tab key.
We will go over the buttons in the order (vertical letters, horizontal numbers) a1, b1, a2, b2, a3, b3. There should be a1, a2, a3, b1, b2, b3. The focus should move across the buttons (by tabs) from left to right, line by line. Now it goes from top to bottom, column by column.
I hope that I have described the problem graphically. In my next post I will describe the problem with the first form in the system installation stage.
Okay I see the problem with button cards specifically - the state is not being read by NVDA. I can work on that. Thanks for the detail.
Regarding the reading order, that is by design, and I wouldn’t consider that an accessibility issue since it is not meant to be a table. If you want to force a specific horizontal reading order, you need to use horizontal stack cards.
I understand that we have few people here with vision problems. So I propose to treat this idea as buying insurance for the future. We never know if we will also need high-level availability.
I do not wish anyone to be blind. However, no one can be sure that he will see well throughout his life. There is no certainty that he will be completely indifferent to this problem.
Old age, an accident, a blind child … there can be many reasons. Lack of accessibility (compliance with WCAG guidelines, guidelines on how to ensure accessibility) exacerbates the problem of poor eyesight or complete blindness.
In old age, with poor eyesight or being completely blind, we want to be able to use technology. After an accident in which we lose our eyesight, we want to be able to continue using technology. We want a child born blind to have open access to technology as well. There are many examples, reasons for the need to take care of accessibility.
For this reason, please, please give your vote for this WTH.
Thank you.
This is an important topic, indeed. Briefly scanning the Home Assistant Discord and this very forum indicates that there were not many discussions in relation to accessibility and WCAG in particular so far.
Therefore, I agree with you that accessibility in Home Assistant should play an important role when developing new features, especially in the user interface.
Accessibility is not for a particular group of people. It is beneficial to everyones user experience and includes all people instead of excluding them.
Compliance with WCAG guidelines makes life much easier.