GUI accessibility with screen reader

[Sebseb01]

Hello,

Is your feature request related to a problem? Please describe.
I can't answer to a poll, beacause i'm blind.

Describe the solution you'd like
Maybe it's possible to activate a special gui when the global "accessibility" setting is enable (and for anonymous a buton on page)

Describe alternatives you've considered
Framadate or doodle have "checkbox" interface with label for each option

Additional context
I'm using the last stable relase on NC20. I have firefox and Orca on debian.

[dartcafe]

Accessability is an open issue. We have to think about possible solutions.

[stefan123t]

@Sebseb01, I know from other projects that making a web application accessible is a lot of work, which requires intensive testing by someone who has e.g a screenreader or other assistive technology enabled.
Would you be willing to test once changes have been made ?

Can you tell us some more about the problems you are facing ?
Are you creating or responding to a Poll ?
Are you using the list view or the table view of the Polls ?
Is there anything that is read out from your screen reader ?
Do you have NVDA installed under Linux / Debian ?
How is Orca helping you, I though it is a character recognition tool ?
How about accessibility of the other Nextcloud apps, is this limited to the Polls app ?

@dartcafe
Is there a Nextcloud accessibility Guide / Standard available ?

We should follow semantic HTML rules and use the defined elements if possible (e.g. headings h1, h2, h3, etc., form fields, table for tables) and apply alternative "screen-reader-only" CSS styled elements in case we are making use of icons without labels.
I just checked the Table view for the polls app and it is built by a table of divs.

A table of divs
https://www.accessibility-developer-guide.com/examples/tables/table-of-divs-experiment/

We should define role="columnheader" in order for screenreaders like NVDA, JAWS, etc. to read them when the user is in a cell belonging to that column. Alternatively you can add them to these options as explanative label (using screen-reader-only css class). If that all does not help you can still define aria-label or aria-labelledby elements that can be read to explain your options.

You can enable the Voice Over function in either Google Chrome or on Safari Browser to get some idea of what it would sound like for someone blind.

There are plenty of ARIA checking tools as plugins. One of the easiest might be the one included in Google Lighthouse as it is quite up-to-date with the current ARIA requirements. For a quick overview in the developer view (F12) select the Lighthouse tab > Generate report. Make sure [x] Accessibility is checked.

For example the four buttons in the main polls view have no aria-label attribute:

• Poll informations
• Ranked order
• Switch to table view / Switch to list view
• Toggle sidebar
  These are only set as tooltip text, but should be repeated as aria-label's to be read by the screenreader.
  Same is reported for the two
• ... (Ellipsis) > Subscribe to notifications and Copy list of email addresses to clipboard
• Delete votes
  entry buttons.

But especially and most important IMHO is that the actual vote entries are not made accessible as Button elements. That way they are neither keyboard focusable (can not be reached via Tab) nor are they read by the screenreader. I assume this is the main concern of Sebseb01. I can only select the aforementioned buttons and cycle through them using Tab key.

[rhiaro]

I've just come to +1 this issue - I'm in a group that sends date polls around, and some of the group who need to respond use a screen reader, and are not able to. I appreciate that you've started thinking through this, per the comment above.

[joepitt91]

Just run into the same issue 3.5 years after it was reported when trying to organise something with a number of screen reader users, fortunately I tested with TalkBack on my Android phone before sending round a link - I must admit the fact there isn't even a sticking plaster solution for this by now is disappointing.

The Web Content Accessibility Guidelines (WCAG) is the international standard for making accessible web content. Yes it is harder to retrofit accessibility, that's why it should be a consideration up front, just like UI, UX, scripting languages, etc.

It is important to note that in a growing number of countries there exists a pre-emptive legal requirements to offer accessible solutions, i.e. solutions must be accessible in case someone needs them to be, not reactively made accessible after someone reports an issue. Issues like this either:

1. Block people who are taking these requirements seriously from using the affected app, or
2. More likely, open them up to civil action for unlawful discrimination.

I'd be happy to help with testing of an accessible voting solution.

[stefan123t]

We would most likely need to change the vue templates under src/js/views,
eg. https://github.com/nextcloud/polls/blob/master/src/js/views/PollList.vue
I have seen that @dartcafe already made some adjustements in #3538 especially 51e8e95 to add aria-labels to some of the NcActionButton to make them more accessible.

@joepitt91 thanks for responding to this issue and offering your help.
Yes accessibility is still an after thought within most projects not only in free / open software.
Especially since developers are not always familiar with WCAG guidelines and best practices.
Did you test / try this change which was committed 2 month ago and should be already in v7.1.4 ?
Note: Sorry, I didn't look into this for quite some time, it simply slipped my attention.

[joepitt91]

Hi @stefan123t, thanks for replying.

I know this isn't a problem isolated to this project or even to open source - apologies if my comments felt personal, this was the "lost count how many-th" accessibility issue I'd run into in a single week, and about the fourth, inaccessible, option I'd looked at for a simple date poll - so may have been a little too wound up to be commenting 😄.

The changes in that PR look promising, however the Nextcloud app store is not offering v7.1.4, I have v7.1.3 installed with no updates available, and this was a clean install of the app a couple days ago as I only just found it - once the package is available to install I'll be more than happy to test.

Fully understand with the delay, too many things to do in not enough time!

[joepitt91]

Looking at the generated HTML for the shared voting page before clicking Register:

              <div class="vote-column">
                <div class="option-item date-box"><!----><!---->
                  <div title="Sat, 24 Aug 2024 11:00 UTC" class="option-item__option--datebox">
                    <div class="event-date">
                      <div class="event-from">
                        <div class="month"> Aug </div>
                        <div class="day"> Sat 24 </div>
                        <div class="time"> 12:00 <!----></div>
                      </div><!----><!---->
                    </div>
                  </div>
                </div>
                <div class="counter">
                  <div class="yes"><span aria-hidden="true" role="img"
                      class="material-design-icon account-check-icon"><svg fill="var(--color-polls-foreground-yes)"
                        width="20" height="20" viewBox="0 0 24 24" class="material-design-icon__svg">
                        <path
                          d="M21.1,12.5L22.5,13.91L15.97,20.5L12.5,17L13.9,15.59L15.97,17.67L21.1,12.5M10,17L13,20H3V18C3,15.79 6.58,14 11,14L12.89,14.11L10,17M11,4A4,4 0 0,1 15,8A4,4 0 0,1 11,12A4,4 0 0,1 7,8A4,4 0 0,1 11,4Z">
                          <!---->
                        </path>
                      </svg></span><span>1</span></div><!---->
                </div><!---->
                <div data-v-9bcceda2="" class="vote-item yes">
                  <div data-v-9bcceda2="" class="vote-indicator"><!----><span aria-hidden="true" role="img"
                      class="material-design-icon check-icon"><svg fill="#3B973B" width="31" height="31"
                        viewBox="0 0 24 24" class="material-design-icon__svg">
                        <path d="M21,7L9,19L3.5,13.5L4.91,12.09L9,16.17L19.59,5.59L21,7Z"><!----></path>
                      </svg></span><!----></div>
                </div>
                <div class="option-item-owner owner"><!----></div><!----><!---->
              </div>

Instead of aria-hidden="true" on the counter icon I'd suggest using aria-label="accepted by" and maybe a sr-only element after the number saying "people" (if you're feeling particularly attached to grammar a switcher between "person" and "people" depending if the number is 1 or not, the reason for this is hopefully clear from what would be read aloud to someone who cannot see the screen at all:

• Current: "Aug Sat 24 12:00 1" (unclear what "1" means).
• New: "Aug Sat 24 12:00 accepted by 1 person" (conveys the same information as is available visually)

Similarly with the vote-indicator - currently other people's votes are completely hidden from screen reader users, other than their names, the vote icon's having an aria-label of "Accepted by {Display Name}", "Maybe for {Display Name}", or "Declined by {Display Name}" would again convey the same information to a screen reader user. To help with navigating votes with many votes, a sr-only "skip individual votes" button which jumps focus to the next vote-column may be a nice quality of life option to include.

In the above example, the user would then get: "Aug Sat 24 12:00 accepted by 1 person. skip individual votes - button, Accepted by Joe".

I've not played with VUE before, otherwise I'd create a pull request.

[joepitt91]

Or you could make the date / time a heading - allowing screen reader users to navigate between dates with screen readers' jump to next / previous heading functionality.

[joepitt91]

On the voting screen, after registering:

1. All the same tweaks as the pre-Register screen.
2. There is an order discrepancy, visually your own voting options are first, but to a screen reader you have to go through everyone else's votes for that option first - I'd suggest moving the user's votes above the other votes in the HTML.
3. The vote-item currentuser should probably have role="button" and an aria-label along the lines of:
   • Initial: "click to vote",
   • Accepted: "Accepted - click to toggle",
   • Maybe: "Maybe - click to toggle", and
   • Declined "Declined - click to toggle".
4. Reflowing the page so all the user votes are next to each other, then other users votes are after would make it much more user friendly - especially if there have been a lot of votes already.
5. Using hidden / sr-only headings to structure the page would be nice too.

With these for the user would hear something like:

Your votes - heading 2.
Aug Sat 24 12:00. Click to vote - button.
Aug Sat 24 14:00. Maybe - click to toggle - button,
... more voting options ...
Other peoples' votes - heading 2.
Aug Sat 24 12:00 accepted by 1 person. Skip individual votes - button. Accepted by Joe.
Aug Sat 24 14:00 accepted by 0 people. Skip individual votes - button. Declined by Joe.
... more voting options ...

And now a screen reader user can get all the same information from the page as a sighted user.

[stefan123t]

@joepitt91 thanks for your tries and common interest in accessibility for the benefit of others. I also found the Polls app to be the most important app where I may engage with other persons having a need for accessibility.
I just upgraded to Nextcloud 29 and the Polls app v7.1.3 which is still one short of the aforementioned accessibility changes to the buttons.
As you suggested / noticed the number of votes / people voting for any of the date / text options is not yet accessible using e.g. the keyboard or some aria-labels. Without marking the vote checkmark boxes as buttons they won’t be reachable using for the browser. IMHO this is currently the main shortcoming besides the images eg the vote-checkbox having no readable aria-label “vote” / “persons” in front of the current vote counter.
In order for a blind person to also cast a vote the whole line having the current vote results must be readable by a screenreader and allow the user to select the individual vote check boxes using eg Tab key and usually the space bar for cycling through the possible vote / decline / maybe choices.

[dartcafe]

Sorry for beeing quiet here. If anyone wants to contribute changes regarding this topic (which is very welcome). Please watch the next branch, since the currently executed vue3 migration will land there. I expect a final merge to this branch until the end of the week.

Final means the code will be completely migrated to Vue3 and (mostly) Typescript, can be build and runs.
Final does NOT mean working in all aspects, there will be a lot of bugs left which are topic of the next weeks.
A first sign will be the release of the 8.0.0-alpha-1.