Post actions on articles list are difficult to trigger on touch screen devices

[Crocmagnon]

Describe the bug

Accessing post modification buttons on an touch screen is difficult because they only appear on hover.

Steps to reproduce (if necessary)

Steps to reproduce the behavior:

1. Go to the articles list
2. Try to click on a button on a device with a touch screen and no mouse pointer
3. It's very hard, you need to think about where the button is going to be and try to tap it

Expected behavior

The buttons should always be visible (maybe dimmer) or in a menu that we can click on safely without triggering an action.

Application configuration

• Single mode or Multi-user mode? Any
• Database? [mysql/sqlite] Any
• Open registration? [yes/no] Any
• Federation enabled? [yes/no] Any

Version or last commit: v0.12.0

[thebaer]

Thanks for the report, @Crocmagnon! This has been brought up before in #94. But that report also mentions a few other accessibility issues, so I'll leave this open to address the mobile problem in particular. I'm currently working around other aspects of the menu design / UX right now, so I can address this.

[Crocmagnon]

Thanks for your response! I would love to see that coming to a future release 😊

[Crocmagnon]

I just realized that in fact the Drafts UI works fine, if it helps :)

[thebaer]

From #359 (comment) by @wiwie:

My proposal is that the links should always be shown on mobile browsers.

I think this is a good, simple way to fix this.

[Crocmagnon]

Why not every browser? So that users have the same UI everywhere?

And just out of curiosity, is it even possible to detect Safari on an iPad among other user agents ? I thought Apple modified it to send the same as safari on desktop so users would be served with desktop sites and not mobile ones.

[wiwie]

@Crocmagnon I guess the original intention of hiding the action links when not used was to keep the UI as lightweight as possible. While I actually also do like that approach and the minimal resulting ui, I'm also inclined to agree with you to say that the current approach of hiding the action links is probably a bad idea in any browser from a usability/accessibility perspective. For example, are screen readers able to read those links? If not, it would basically exclude blind people from using writefreely.

An approach to keep the UI minimal while still being accessible could be to add a small collapsible menu (eg drop down). I would think that if implemented correctly these can be interpreted by screen readers also.

[DavePolaschek]

Note that Safari on iPad masquerades as safari on Mac OS, so for at least that one mobile browser, "is this a mobile browser?" is likely to fail.

I tried using the classic editor for write.as, mostly to have easier "set a title" functionality, but there were a lot of things failing there when trying to use if from safari on an iPad, so I turned that off.

Probably should be a new issue, but there’s nothing in the tutorials about how to set a post title without using the "classic editor."

[cblte]

As a quick fix: you could use some css styling to have the links always shown.
Just add

.hidden {
  opacity: 1;
}

anywhere to your custom css.

[DavePolaschek]

That works, thanks!

Interesting thing from a "fixing the bug" POV is that the commands don’t seem to be there when looking at an individual post, but they are there when looking at the whole list on the blog. That’s almost the inverse of what I was expecting. When I want to interact with a single post, I go to that post, rather than going to its parent blog.

[thebaer]

Mistakenly closed this with a different commit. #449 will close this, once merged.