A11y improvement #2322
A11y improvement #2322
Conversation
add nav landmark for links labeling the purpose of nav in page-header labeling the meaning of total number in page-header title
|
I am a blind screen reader user and I am looking forward to accessibility
improvements for the webinterface of Miniflux very much, allthough I must
say that the interface is in general good to use already.
Navigating through e.g. the list of article by headings is more easy then
using the left or right arrow keys because I do not have to switch the
screen reader mode. However, there is one big problem still I think. If the
last article is focused by the screen reader and I execute the screen reader
command to jump to the next article the focus will jump to the first item
of the article list and navigating through the list will start from
the beginning of the article list. This is also the case if the arrow keys
are used. This is normal behaviour of the screen readers I think but
because of this behaviour sometimes it is hard to know whats the current
position in the article list and if all items of the list have been already
explored. So something that let the screen reader recognize the position of
the listitem would be very helpfull, but I do not know if and how this can
be implemented.
Also it would be very helpfull if the actions for an article would be
buttons and not links. With actions I mean to mark an article as read or
unread, star an article, save an article and open the link for the article
externaly. If those elements would be buttons and not links a screen reader
user can navigate those elements also maybe more quickly.
However, I'll try the new improved layout with the headdings for the
articles as soon as a Miniflux release is available with this changed layout
and see how it works. Maybe we can take a look after this first changes and
improve accessebility even more, depending on the problems that then still
exist.
I'd like to point out again that the Miniflux interface is already good to
use with a screen reading software. The layout is minimalistic and only the
necessary things are displayed in a simple way. Thats great and I hope it
will stay this way because accessible RSS readers that can be used with a
screen reading software are very rare to find and Miniflux is the best in
this case AFAIK. I think there are only a few little things to change to
make accessibility even better. So a big thank you for Miniflux in
general and a big thank you that the userinterface is that good use also for
blind people!
|
|
@sonor3000 Thanks for your feedback. May I ask which screen reader and device you are using? I'll take a look at the jump to first item problem. The article list position may be fixed by adding feed role and set aria-posinset, aria-setsize attributes. I've thought about differentiate links and buttons. I didn't change that is because I thought it won't affect user experience that much, so thank you for pointing out that. @fguillot I'll work on these issue above. Thanks for your review recently. |
|
Am 01.02.2024 um 14:04 schrieb Tân Î-sîn ***@***.***>:
@sonor3000 Thanks for your feedback.
Thank you very much working on this issue! Thats great!
May I ask which screen reader and device you are using?
My main system is a Debian linux box with the orca screen reader. Because I do not know a RSS reader for linux which is useable for blind users on linux and which is working with Miniflux I am searching for an accessible way to use Miniflux with this system that is easy to use and where I can check content quickly. I think this will be the case when your changes will be included. Ofcourse I can use the webinterface already, but its not that efficient with a screen reader.
My second system is a Mac book with the VoiceOver screen reader. There I am using the ReadKit app which connects to Miniflux via the Fever api. That is working very good I can read my RSS feeds quickly and efficiently.
The third system is the Lire app on my iPhone, also with the VoiceOver screen reader. I use this system when I am travelling and when I am not able to use a computer. The Lire app is perfect regarding its features and its usability. Before I was using the Firey Feeds app which was also great.
|
|
Am 01.02.2024 um 14:04 schrieb Tân Î-sîn ***@***.***>:
The article list position may be fixed by adding feed role and set aria-posinset, aria-setsize attributes.
Yes, that is what I also found. But I am no web programmer and so putting this into a PR is on my todo list for a long time already :-).
I've thought about differentiate links and buttons. I didn't change that is because I thought it won't affect user experience that much, so thank you for pointing out that.
Yes. I don’t know if this will change the interface to much and if it will look and feel like the current layout. I also thought about a special theme optimized for screen reader users, but as said…, I am not a web programmer and therefore its another item on my todo list which takes me to much time to work on and learn how to create such a theme :-(.
However, I know at least three other screen reader users which would be happy about a more efficient interface. They are also using Linux and one of them Windows.
Many thanks for your work!
|
|
@sonor3000 I've tested the feed role and aria attribute solutions. Maybe because this role is a new feature, Android TalkBack, VoiceOver, Linux Orca didn't announce the position value. But I found that when navigated to the next headings on the last article, TalkBack and VoiceOver will announce they can't find the next heading, and Orca will jump to the first item and announce this action. So I think this problem can be solved by adding heading role for article element. |
|
On Thu, Feb 01, 2024 at 09:29:38PM -0800, Tân Î-sîn wrote:
***@***.*** I've test the feed role and aria attribute solution. Maybe
because this role is a new feature, on Android TalkBack, VoiceOver, Linux
Orca didn't announce the position value.
I've never seen that this position value for area was anounced by a screen
reader, but maybe I have not yet used an application where this attribute
have been used. For orca and maybe nvda it will be implemented quickly I
think and if it is really not yet working. I'll test with different screen
readers if your new PR has been included in Miniflux.
But I found that when perform navigate to next headings on the last
article, TalkBack and VoiceOver will announce they can't find next
heading, Orca will jump to the first item and announce this action. So I
think this problem can be solved by adding heading role for article
element.
Yes, this will work for sure.
Thanks again for your work!
|
|
@sonor3000 I've noticed that when the confirmation interface pops up (e.g., clicking "Mark all as read" will show "Are you sure? Yes, no"), the screen reader will lose the current focused positions. Does this behavior affect you while you're using? If we use the HTML dialog in modal mode, the browser will handle the inert and autofocus the dialog.
And also, get the ESC keyboard shortcut to close the dialog. But the only problem is that it will change the layout visually. @fguillot Do you suggest that we change the current user interface into a dialog? |
|
Am 02.02.2024 um 15:25 schrieb Tân Î-sîn ***@***.***>:
@sonor3000 I've noticed that when the confirmation interface pops up (e.g., clicking "Mark all as read" will show "Are you sure? Yes, no"), the screen reader will lose the current focused positions. Does this behavior affect you while you're using?
This behaviour is only a problem with Safari and VoiceOver on my Mac. There not only the focus of the screen reader gets lost, also the buttons for „yes“ and „no“ are not read. If I use Firefox, also on the Mac, it works and on other operating systems the modal is also OK, no matter what browser or screen reader I am using.
However, the dialog to mark all items of a feed read ist really not ideal regarding accessibility. I don’t know how to make it better, but I am using webbased applications where this kind of things are much more useable for me.
|
I have never used the |
|
There is another thing that came to my mind that till no prevents me to work a lot with the web interface of Miniflux.
Lets say y I have a article list with ten items on a page and I want to mark all read except
the third one because I want to read this article later.
Currently I have to navigate to each of the article and set the status which might be quick and easy when using the mouse or if you can see on the screen the focused article. With a screen reader this is a very time consuming action :-(. I am aware that I can change the status with a keyboard shortcut but depending of the screen reader that is used the focus gets lost and the screen reading software jumps to the beginning of the page. After your changes are included in a new release I’ll test again this behaviour.
In my different client software I can mark articles above and below as read which is very easy and fast but I really wish to use Miniflux without a client software, because I do not have a useable RSS client for Linux.
However, thanks for accepting the patch and thanks for the work. I am looking forward to test the new release!
|
|
@sonor3000 This PR might meet your request. |
|
I'm a screen reader user and I happen to see these changes because I have Watchtower set up to pull down the latest nightly docker images. I use NVDA and JAWS on Windows, primarily working in Firefox but also Chrome. These updates have entirely changed the way entries are read out, and, on Windows at least, not for the better. This has made navigating without the keyboard shortcuts easier, but for those that use these (as opposed to screen reader navigation), there are a few issues. Navigating with j/k via the keyboard between entries, I now hear: All for a single item. This is likely due to the alt text on the feed icons, though I would strongly reconsider having heading roles for these items as it is not semantically correct, even though it may make certain flows more usable based on how each user uses their screen reader. Additionally, the feed name is now read out before the actual article, which was not behavior exhibited before. Categories are also read differently (this is getting added to the aria-label, it seems): Instead of "Technology (1150)". The same behavior as entries is also exhibited when using j/k to navigate; items are read three times. Mark all as read buttons for each category use an aria-describedby attribute that points at the category title, which results in the category being read out again when this button is focused. I'm sure there are others that I haven't caught yet. Screen reader users are not a monolith, and everyone has different models of interacting with content. I propose staying with the original design, which was more semantically correct and allowed users to navigate by the article landmarks if they wish to add this to the navigation roter on mobile or bind a key using their screen reader of choice. This model has worked well for years, and although I recognize and applaud you for implementing accessibility, this changes the paradigm significantly and is overly verbose for those that may not need explanations of where they are. I'm open to discussion and comments on this; I stumbled upon this issue trying to track down the commits that were behind these changes, and I'm glad to see some ongoing conversation. |
|
Additional a11y bug: making options buttons is semantically incorrect. For example, we now have buttons by feeds that read: If this is a button, it should use a @fguillot Please consider reverting these changes until we can reach a consensus on what this should look like. If this gets rolled into a final release it will be confusing for screen reader users at best (specifically those that are already used to the layout prior to this set of changes), and downright problematic at worst. |
Why do you consider it is not semantically correct?
Does items are read three times affect user experience a lot?
After the translation improvement, this key is removed. Could you help on this one, @fguillot ? |
|
I'm a screen reader user, use Android TalkBack most of the time, in desktop I use Linux Orca and macOS VoiceOver. I made the changes base on the concept, no matter which way you use, should get enough information. According to WebAIM Screen Reader User Survey for Finding Information: Navigate through the landmarks is the first choice when I'm using screen reader. Article is counted as landmark in Android TalkBack. But the problem I encountered is TalkBack won't announce the text when it's a link when navigate through landmark on article element. The way to fix this is to set the aria label to the article element. So people who preferred to navigate through landmarks can get enough information. Add heading role can let people navigate through headings, and which is the method that has most user preferred to. And also my second choice when the page didn't set landmark correctly. For example, in category entries page, heading level one tell user that what the category is, and heading level two, the article title, indicate that is article is the subsections of this category. Article landmark, headings, links happened to be the same in this case, but it won't have to be. For example, Article landmark can set the label to announce more information just than article title, it could add feed name, category, maybe possible read time or small part of the paragraph in aria-describedby. Heading should stick to article title is more semantic correct. And as for the link, its actual meaning is "go to the entry page", instead of direct wrap the whole heading text as link, set the actual meaning is more semantic correct. I think we could edit the label for each role specifically as improvement. But I think these three roles are labeled by article title has announced the enough information to users. User may think it's redundant that it announces the same text three times. But each role label has it's meaning when navigate by a different role. The feed name is announced before article title, is because the layout display this way visually, the feed icon has alt text of the feed name is the first item in entry section. The title link is the second element of the entry section. But the keyboard navigation is focus on the title link, the feed icon is omitted. Img tag with alt text set means it has meaning to users, and actually it is. And for the aria-describedby for button, when I navigate through button, there are tons of button has the same label as read, star. Sometimes I'll get confused which entry is this button's target. But yeah, this could waste users time when use screen reader read all content function. |
Because they aren't headings visually, nor are they sections of the page. These are, for all intents and purposes, posts/entries in a list. I would consider a feed role with the enclosed items as articles to be more valid, though I'm open to alternatives on this.
Absolutely.
I don't think it's our responsibility to accommodate for user agent deficiencies or screen reader bugs (this seems like a bug, at least.) Especially if the fix ends up degrading the experience for other screen readers and platforms.
Feed entries and category items are already enclosed in an unordered list, which is navigable by all popular screen readers, in my experience. I'm not sure I see the benefit here.
It is redundant, and previously these were just announced as articles and links simultaneously with one copy of the text using NVDA. I'll need to do further testing with macOS. Unfortunately I don't have an Android device on hand. Having the entire item read once for each role that it inherits is bad UX, in my opinion. But I'm just one person.
I specifically objected to this for the following reasons:
More than anything, this is showing me that there is--as I mentioned prior--not only one way of interacting. :) I just hope that we can keep all ways congruent with each other, as they were previously. Maybe the overall answer is having an accessibility setting that allows you to configure if headings should be used for feeds and feed items, in what order items are announced when using the keyboard, etc. As this is a web app, I've always considered j/k and the arrows the most accessible and uniform way of navigating, since its also the way a non-screen reader user that uses the keyboard would navigate. But I am not the end all be all on interface usability. |
|
@distantorigin
So the category name as heading level one, informs that the article title as heading level two is related to this category. If it doesn't look like a heading, it's more like a visual design problem. So, the benefit for headings in article element is:
If the user is already familiar with this page, then the user might know there would be a list can be navigated through, what about the new user? |
|
@krvpb024 If we want to use headings as an alternative way to navigate, that's fine. I'll back down on this one, but we need to make sure all models of interacting, especially the existing models via keyboard only, are just as accessible. Currently these fixes cause regressions that I've detailed above. I will also posit: Having headings for each section of the page allows a new user to familiarize themselves very quickly. In version 2.0.51, you can navigate by heading to get to the Unread feeds (or categories, or feeds, depending on the page) and then skim further to see your feeds. Users do not singularly navigate by headings; it's a methodology of identifying what major elements exist on a page.
So you're saying the visual design should follow the accessibility design, even though it may not make sense to be that way? I'm not entirely sure what this means, can you clarify At the very least, these changes should be togglable or configurable, much like themes are. Ideally, however, we can reach a solution that makes everyone happy. I will take a stab at the templates in use and see if I can propose something that retains the old functionality as well while carrying these changes forward for the headings approach. Until we do reach a solution that does this, I hope that we can put these changes on hold as to reach a resolution that won't involve regressions or usability complications. |
No, it's not redundant. It doesn't announce that much information in previous version, is because previous version didn't provide such information for user who need that. |
|
@distantorigin I talked about its visual design problem is because when I ask you why do you consider it is not semantically correct? You mentioned:
|
|
@krvpb024 Yes, it did change the behavior. I'm talking about navigating via the keyboard with J/K or the arrows, not by landmark with your screen reader. Previously, this read the title of the article. Now, it reads three times when navigating with Miniflux's native shortcuts, once for each role. I've been able to replicate this with JAWS and NVDA. This is not ideal, and is very much redundant. |
|
Hey, previously the search bar was display:none and this changed removed that. Home come? Can we add that line back? |
|
@fedgrant Hi, the search bar is wrapped by HTML details and summary element to control the display toggle. So the CSS display none is removed. |
|
On Mon, Feb 05, 2024 at 02:15:15PM -0800, distantorigin wrote:
Navigating with j/k via the keyboard between entries, I now hear:
Hacker News: Front Page Meta cuts off third-party access to Facebook
Groups article
Hacker News: Front Page Meta cuts off third-party access to Facebook
Groups heading
Hacker News: Front Page Meta cuts off third-party access to Facebook
Groups link
This is not the case with orca on Linux. There the title for the article
is only spoken once. With VoiceOver on a Mac the title is spoken twice.
In both cases I used j/k for navigation. I agree that the title of an
article should only be anounced once on all plattforms, if that can be done
somehow.
When navigating by headdings with h all is fine with Orca or VoiceOver.
Additionally, the feed name is now read out before the actual article,
which was not behavior exhibited before.
I also think this should be changed because it slows down scrolling
through the articles a lot. In the past I removed this icons from the theme
too not have this behaviour, but since I run Miniflux on Kubernetes and not
longer with Docker I do not make this change anymore. But that this icons
are announced was always very bad for the UX with a screen reader :-(.
So, many things are better now, especially when navigating by headding or
the buttons, but if j/k is used to navigate through the articles for me also
to much is spoken by the screen reader on some plattforms.
Categories are also read differently (this is getting added to the
aria-label, it seems):
Technology, page.categories.unread_counter: 1150
Instead of "Technology (1150)". The same behavior as entries is also
exhibited when using j/k to navigate; items are read three times.
This is OK for me with Orca on Linux, no matter if I use h or j/k to
navigate through the cathegories. But on a Mac with VoiceOver the cathegory
is spoken twice.
Mark all as read buttons for each category use an aria-describedby
attribute that points at the category title, which results in the category
being read out again when this button is focused.
Yes, the same here with VoiceOver and Orca.
For me the new layout is much better when navigating by headdings and using
the new buttons, but if j/k is used there are the described problems. In
general a new layout should improve workflow and make things easier and
faster then it is with the current layout, so announcing things twice or
read the feed icon before the article title is not that good because it
slows down scrolling through the content a lot, even such things might be
semanticaly correct.
Maybe it would make sense to create a seperate minimalized and optimized
theme for screen reader users that can be selected in the settings if
someone likes to use this theme...
|
|
Agreed with everything you've noted here, @sonor3000. I don't have a Linux or Android device to test on currently, but your macOS experiences align with mine.
This was fixed in commit 5ce5c47 and was a translations issue. |
|
So lets hope that all PRs that have been created by @krvpb024 will be
commited soon, so wie can test again. The problem that the icon and its
alternate text is spoken before every article should also befixed in
another PR.
@fguillot Can you commit the PRs please so we can have another look?
@krvpb024 Thanks again for your work! I think wit a bit testing and some
little fixes things will go well!
|
|
@krvpb024 I dont have a screen reader. I just noticed that the search bar appeared at the top of page and I had never seen it before and tracked it down to this change. This is what it currently looks like.
I liked it better without the extra search tab. Is there any way to revert that portion back? |
|
With the newest nightly build for me the UX of the web interface is nearly perfect ;-).
On Linux with Orca I have no more issue. I can quickly navigate by headding and / or j/k through article lists and nothing is spoken twice, no feedname and its grafic is spoken, e.g. Also the buttons to save or star an article are fine. Perfect and much more efficient for me as far I can see till now.
On a Mac with Safari the modal to mark a page as read is also useable now, that did not work before. But if I navigate with j/k or with arrow left or right through the articles they are still announced twice. If I navigate by headding all is fine.
So for me there is only issue left, which is the thing that on the Mac the article title is spoken twice when navigating by arrow keys or j/k. For me thats no big problem because I can skip to the next article before the title is announced the second time. But maybe this is also solvable.
Thanks again for working on this!
|
|
@fedgrant This change is because in the previous version, the search form was inside the nav element. And it was hidden by Doesn't this layout change affect your usage a lot? |
|
@sonor3000 I've made some changes to deal with this screen reader behavior in this PR #2348. I've tested on macOS VoiceOver and Windows NVDA, and it will only announce the title once. |
Do you follow the guidelines?
Improvement
I have tested the screen reader on Android (TalkBack), iOS (VoiceOver), macOS (VoiceOver), Linux (Orca).
Add skip to content link
Skip links can help keyboard users navigate to the main content instead of tabbing through all the focusable elements.
This technique is recommended by the W3C
Add nav landmark to page-header links
Wrap the nav tag around page-header links so that the screen reader user can navigate to them through landmarks.
Add a label for the page header nav according to the WAI ARIA Authoring Practices Guide.
I didn't add a label for the first nav because the nav in the header already has a semantic meaning for global nav.
Search landmark
Add a search landmark for the search form so that the screen reader user can navigate to it through landmark.
I moved the search element out of nav because when the nav css display is none, screen reader can't discover there is a search landmark. It's difficult to find a search form for screen reader users when in mobile layout.
Improve a11y for disclosure menu
The current mobile layout will hide nav element, but there's no clue for the screen reader user to notice that tapping the miniflux logo will expand the nav menu. This also happened to the search form.
I added the aria attribute to the nav element and wrapped details and summary tag in the search form to fix this problem.
Search form
Using placeholder for labeling input would cause some problems, so I added aria-label to fix this problem.
And I added a submit button for mouse and trackpad users in order to perform search actions.
Article element
Remove the redundant article role.
Add a h2 heading to the article element so that the screen reader user can navigate the article through the heading level. This would also fix the issue that screen reader users encountered with the current keyboard navigation method.
Add an aria-label for the article element for the screen reader, and when they navigate by landmark, they will have a better understanding what this article is about.
Remove the icon image alt in feed_list, it's the same as the feed title. It didn't provide extra meaning for the screen reader users, but it will cause them to have to navigate twice in order to get the next element.
Add sr-only css class for screen reader user
sr-only class will hide the element from the page but can still be discovered by the screen reader.
For example:
Example (2)
The screen reader will say, "Example: Number of unread entries: 2"
This will help the screen reader user know what's the meaning of the number is.
Differentiate between buttons and links.
Buttons and links have different semantic meanings. Screen reader users can navigate these two elements separately. Changing links that could perform actions to buttons can improve the user experience.