Accessibility of sources-list

[heull001]

The source-list (selfoss.link/manage/sources) is not very accessible yet. Every function is usable, but its not comfortable to navigate with screenreader here. The first problem I think, form is not the right tag to group an item. I think, article or maybe section would be better here. By using form, not every screenreader notices that there should be a newline between the items.

Also it would be helpfull to tag the source-titel as headline, most screenreader-users use headlines to navigate.

[jtojnar]

Thanks for reporting. I tried to improve it in https://github.com/fossar/selfoss/pull/1345. Article did not feel right so I went with list items. You can download the pre-built version at https://github.com/fossar/selfoss/actions/runs/2658340140.

[heull001]

Great, it's much better now. The list works perfect here, I was unsure about article too.

One more suggestion, it would be helpfull to autofocus the first Element of the form, when pressing the edit-button.

[jtojnar]

Good idea, pushed another revision. https://github.com/fossar/selfoss/runs/7324516538?check_suite_focus=true

I am still unable to test it well since the only screen reader I have access to is Orca and it seems to freeze my web browser.

[heull001]

Works fine, thanks.

Testing with Orca could be a problem with your desktop. Orca just works with GTK-desktops like Mate or Gnome, not with QT-desktops like KDE.

[jtojnar]

I use GNOME and Firefox freezes for me when enabling it. But it might just be that I have too many tabs open and too many sources in selfoss.

[heull001]

That's possible. So, if you need someone to test something with a11y, especially for screenreader-users, just contact me, I'm using selfoss several times a day, so I'm very interested in good a11y.

[akash07k]

I too can help regarding testing accessibility. I'm a full time accessibility consultent and developer

[jtojnar]

Thanks for the offer. I think feedback from the actual users is the most important for improving the usability. Particularly if there is any part of the UI that is inaccessible.

Colour chooser accessibility

Actually, one change I am not sure about in 2.19 is making the tag colour chooser accessible via keyboard. The side effect is that the user now needs to press Tab twice to jump to the next tag in the list in the sidebar. That might be annoying to e.g. blind users who use keyboard to navigate but have no use for coloured tags. Or perhaps they use more sophisticated navigation tools than pressing Tab so it does not bother them at all.

On the other hand people hard of seeing might benefit from the ability to change tag colour that might not have been available to them previously if they are not able to use a mouse.

Also note that the colour chooser dialogue is currently not very usable for people who rely on screen readers – there are no labels for colours. Most of them probably do not need to change tag colours but I can imagine a hard-of-seeing person relying on a screen reader for cues like currently selected colour – perhaps they would benefit if I labelled all the colours and then screen reader would say something like “Changing colour of tag ‘news’, ‘salmon’ currently selected”.

Pagination

As you suggested in the past, another area for improvement would be the pagination of the articles. I still need to redo the client-side model before we can tackle https://github.com/fossar/selfoss/pull/1135 but hopefully that will make it for selfoss 2.20.

There are still some unresolved questions like:

1. What issues do people using accessibility tools encounter with the current list?
2. Is it just that scrolling, which they may not have control over, causes new articles to load, potentially interrupting their reading? It is possible to require explicitly clicking the “Load more” button with auto_stream_more=0 option.
3. Or do they find having ever growing outline difficult to navigate and they want to remove the articles they already read from it? Then implementing show_only_current_page=1 option might be a sufficient solution.
4. Is the existence of page numbers and the ability to jump to a specific page important?
5. What should happen with page numbering if new articles appear?
6. Does the new page need to be marked with aria-live or something?

Reading list

For myself in the future:

• https://crocoblock.com/blog/pagination-vs-infinite-scroll/
• https://www.webaxe.org/infinite-scrolling-and-accessibility/
• https://www.smashingmagazine.com/2016/03/pagination-infinite-scrolling-load-more-buttons/
• https://www.boia.org/blog/is-infinite-scrolling-accessible
• https://blog.logrocket.com/guide-pagination-load-more-buttons-infinite-scroll/

[akash07k]

I'll reply to all your pointers soon, I'm out of city and writing from home,

I have some ideas to make color chooser and pagination accessible.

Actually, 2.19 took around 3 years to be released, so, if I send PRs to make pagination etc. accessible, any rough idea that how much time 2.20 may take to release?

On 10/14/2022 7:46 PM, Jan Tojnar wrote:

Thanks for the offer. I think feedback from the actual users is the most important for improving the usability. Particularly if there is any part of the UI that is inaccessible.

Colour chooser accessibility

Actually, one change I am not sure about in 2.19 is making the tag colour chooser accessible via keyboard. The side effect is that the user now needs to press Tab twice to jump to the next tag in the list in the sidebar. That might be annoying to e.g. blind users who use keyboard to navigate but have no use for coloured tags. Or perhaps they use more sophisticated navigation tools than pressing Tab so it does not bother them at all.

On the other hand people hard of seeing might benefit from the ability to change tag colour that might not have been available to them previously if they are not able to use a mouse.

Also note that the colour chooser dialogue is currently not very usable for people who rely on screen readers – there are no labels for colours. Most of them probably do not need to change tag colours but I can imagine a hard-of-seeing person relying on a screen reader for cues like currently selected colour – perhaps they would benefit if I labelled all the colours and then screen reader would say something like “Changing colour of tag ‘news’, ‘salmon’ currently selected”.

Pagination

As you suggested in the past, another area for improvement would be the pagination of the articles. I still need to redo the client-side model before we can tackle #1135 https://github.com/fossar/selfoss/pull/1135 but hopefully that will make it for selfoss 2.20.

There are still some unresolved questions like:

1. What issues do people using accessibility tools encounter with the current list?
2. Is it just that scrolling, which they may not have control over, causes new articles to load, potentially interrupting their reading? It is possible to require explicitly clicking the “Load more” button with |auto_stream_more=0| option.
3. Or do they find having ever growing outline difficult to navigate and they want to remove the articles they already read from it? Then implementing |show_only_current_page=1| option might be a sufficient solution.
4. Is the existence of page numbers and the ability to jump to a specific page important?
5. What should happen with page numbering if new articles appear?

— Reply to this email directly, view it on GitHub https://github.com/fossar/selfoss/issues/1344#issuecomment-1279069234, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQWBM7U7YGRFZSVMFZLPF3WDFTKNANCNFSM53K5XG3Q. You are receiving this because you commented.Message ID: @.***>

[jtojnar]

We currently do not have any hard blockers so I can imagine much shorter development cycles. Depending on the number of new features we can probably do six or even three months. But please discuss the ideas before starting to work on it. Especially for the pagination since I will still be reworking the data model and resolving merge conflicts might be painful.