Can't use post publish dropdown with a screen reader

[ndarilek]

Hello,

I'm a screen reader user, and have occasionally tried and failed to use Ghost. My blocker is the button for setting a post's publication status. This control has the following issues:

1. It is apparently a dropdown, but only reports as a button. You may want to use aria-expanded here.
2. When clicked/expanded, none of the child elements are focusable, or keyboard-interactable in any way.
3. I'm using Orca under Linux, and even using its mouse emulation mode, I can't seem to click on any of the publication options.

I looked at the code but am not overly familiar with Ember, so I'm wondering if this would be a quicker fix for someone with that knowledge? In particular, it looks like you may be using a basic-dropdown component, but I'm not clear if that ships with core Ember/a third party dependency, and if it gives you the flexibility you need to fix this.

The quickest fix would likely just be making the dropdown elements <button/> so you'd get accessibility for free. The second quickest would likely be slapping role="button" on whatever elements you do use, setting tabindex="0", and adding key handlers for space/enter. If you use this pattern lots, make that a component for reuse.

If someone were to start a PR, I'm happy to test it. But a PR would also show me what specifically to change, so I can probably iterate on it myself and fix any remaining issues. But, chances are that if you can tab/arrow to the publication states and activate them via the keyboard, then things will just work.

In the meantime, is there any other way to tweak publication state other than spelunking in the database? :)

Thanks.

[MarcoZehe]

I fixed this issue with aria-expanded not being set when the dropdown is collapsed, in cibernox/ember-basic-dropdown#556. Once a new version is released and the package updated in the Ghost Admin client, this fix will automatically propagate.

However, the other problem is that the children of the dropdown are being aria-owned into the button element. So they become children of the button on the accessibility tree side. NVDA deals with this okay‘ish, VoiceOver, too. But Orca seems to be less forgiving. The problem is that, if this wasn‘t the case, the new content would be far far away from the actual button DOM-wise. Not sure how to solve that in the basic-dropdown component, which is where this fix must happen.

[ndarilek]

Ah, so the menu options get added directly inside the <button/>? That is going to make things a bit more complicated, particularly as I don't think Firefox even exposes button text to Orca in a way that can be interacted with (I.e. no reading character by character through button labels.) Wondering if it'd be worth transitioning to using `<details/>` and `<summary/>` instead? I'd try, but would almost certainly break the styling. Is it legal HTML to have interactive elements as children of buttons? Not that that ever stopped anyone before, but it'd probably be easier to make a case for fixing Orca if it wasn't handling correctly-formatted HTML. :)

[ndarilek]

I don't want to hijack this issue, but are there any alternative ways of publishing to Ghost? Spent some time seeing how hard it'd be to move dropdown children out of the button, and I think it'll take me far down a rabbit hole that I don't have the time to explore right now. I'm trying to create a membership site, and my options are currently: * Fix this accessibility issue so I can use Ghost under Linux. * Find an alternate means of publishing that doesn't use the inaccessible-to-me interface. * Pursue my initial plan of using Hugo, and rolling my own auth integration using Cloudflare Workers and a third-party auth provider. 1 is probably beyond what I have time for now, and involves learning way too much. 3 is lots of work, but uses technologies I already have lots of familiarity with. That just leaves 2, but so far I'm not finding alternative publishing methods, unless the Ghost desktop client uses a different interface. Thanks, and apologies for the noise. I'd hate to not use Ghost because there's some alternate way to publish that I just haven't found yet. :)

[MarcoZehe]

@ndarilek I think I fixed it. Can you try this preview? It opens a set of unlabeled buttons from the top navigation bar, but if you call up Docs, then How To Use, there are more there that show some more useful content when expanded.

[ndarilek]

Nice, the dropdown at that link does expose a series of unlabelled buttons. Just a couple issues that may not be specific to what I reported but are still a bit odd: 1. When I attempt activating the dropdown with Enter, I hear "Collapsed: collapsed." I realize that isn't exactly what I reported, but if you're patching this dependency, would it be possible to address that as well? Space works fine. Not sure whether that specific behavior is part of the component itself, or if the markup representing the collapsed item is separate and not directly owned by the component. 2. The buttons don't appear to receive keyboard focus. Again, not sure if that is specific to the dropdown component, or if the markup you used in your example just doesn't add the tabindexes. If the latter, it should be easy enough to add them in Ghost itself. Thanks for the fixes!

[MarcoZehe]

1. When I attempt activating the dropdown with Enter, I hear "Collapsed: collapsed." I realize that isn't exactly what I reported, but if you're patching this dependency, would it be possible to address that as well? Space works fine. Not sure whether that specific behavior is part of the component itself, or if the markup representing the collapsed item is separate and not directly owned by the component.

It is, but it is a separate issue. Enter is merely being passed through, and the event for some reason fires twice. Space is handled differently, its propagation is being stopped, so it only fires once. I will file a new issue and correct that so that Enter and Space always behave the same.

2. The buttons don't appear to receive keyboard focus. Again, not sure if that is specific to the dropdown component, or if the markup you used in your example just doesn't add the tabindexes. If the latter, it should be easy enough to add them in Ghost itself. Thanks for the fixes!

It is not my example actualy. It's provided by the original author, I'm just patching things. The reason is because in the DOM order, these items are appended to the end of the document. So simply tabbing forward doesn't go to these initially, but will land on them eventually. This is the thing with aria-owns, it changes the accessibility tree, but not the DOM order, so keyboard focus sometimes acts a bit odd. Having said that, these examples have a separate bug in that the items are always appended at the end, not the place the component actually specifies where they should be added. But I am not sure why, and am not so keen on fixing that part TBH.

[ndarilek]

Makes sense, and thanks again for these fixes. Is there a PR I can watch? Happy to do the work of testing the new dependency in Ghost, and of submitting a PR to bump it should it work here.

[ErisDS]

I don't want to hijack this issue, but are there any alternative ways of
publishing to Ghost?

Just to quickly talk about workarounds - there are lots of ways to publish without using Ghost Admin. At its heart, Ghost is just an API, and Ghost Admin is the default client. You can use a 3rd party client or write your own client just to do what you need.

There are many 3rd party clients listed on our integrations page such as Ulysses or iAWriter.

If you want to write your own work around, documentation for our Admin API client lives here: https://ghost.org/docs/api/v3/javascript/admin/ and documentation for how to update a post lives here: https://ghost.org/docs/api/v3/admin/#updating-a-post. With the API client, it shouldn't take more than 10 lines of code to grab a post by ID or slug, and update the status to published.

[ndarilek]

Thanks, wasn't familiar with the integrations functionality, or indeed whether or not integrations were what I needed. I'll try working some curl magic until we can land this dependency change. I'm under Linux, and am not immediately sure if any of the third-party clients would work for me.

[ndarilek]

I've successfully slapped together a few lines of JS to publish posts and pages until this dependency update lands. Now I'm having another issue, and I don't know if it's related to this one or not. Once I've published a post, I can't figure out how to save changes I make. They appear in the editor, but despite my page claiming that it is published, I never see the updates. Likewise, trying to navigate away from the edit page prompts me to leave or stay because of unsaved changes. I'm not sure if there's a Save button somewhere in this dropdown that I can't find, or if there's another inaccessible control I can't find at all. Happy to open a new issue--the challenge is that I don't know enough to determine whether this is related or not. :) I've checked https://ghost.org/faq/using-the-editor/, please let me know if there are better docs for my purpose. Thanks.

[kevinansfield]

I fixed this issue with aria-expanded not being set when the dropdown is collapsed, in cibernox/ember-basic-dropdown#556. Once a new version is released and the package updated in the Ghost Admin client, this fix will automatically propagate.

I've forced an update of Ghost-Admin's sub-dependencies so the ember-basic-dropdown upgrade will go out in today's release 🙂

[ErisDS]

I'm not sure if there's a Save button somewhere in this dropdown that I
can't find, or if there's another inaccessible control I can't find at
all. Happy to open a new issue--the challenge is that I don't know
enough to determine whether this is related or not. :)

It is definitely the same problem - the same pattern used for publishing is reused for updating. There's an update dropdown, which (same as the publish dropdown) has 2 radio buttons that let you toggle between unpublishing or keeping the post published (keeping it published is the second, but default option) and then there's an "update" button.

To be honest I never use this workflow, I always use cmd / ctrl + s. I don't know if that helps.

It's not helpful immediately, but these workflows and interfaces are due an overhaul later this year as it's not lost on us we've outgrown them.

[ndarilek]

Ah, so there *are* keyboard shortcuts. :) Are they documented anywhere? I've seen them mentioned here and there, but no comprehensive list. Spent some time yesterday unsuccessfully looking for one. I did eventually succeed with some combination of ctrl-alt-S, ctrl-S, etc. under Linux, though I'm not sure which ultimately did it since there wasn't accessible feedback, and my screen reader may have eaten some of them. Thanks for letting me know that they're possible. Are there also keyboard shortcuts to publish posts? I'd like to skip switching to the command line and running my scripts if at all possible. :) As an aside, apologies for the forum post. It wasn't my intent to pester the team with a duplicate--I was genuinely hoping that an end-user might step in and help me out, thus saving you the effort. Should I post future accessibility questions to the forum first, then only open up GitHub issues for anything that is definitely a bug? I opened this because, as a web developer myself, I was pretty sure it was accessibility-related. But I could easily see a Ghost user telling me about the existence of editor keyboard shortcuts, and was disappointed that no one had the chance to do so unless they just happened to know about this specific issue. In any case, thanks again for the help.

[ErisDS]

By default we try to make sure the keyboard behaves as you'd expect, so save, undo, redo, select all, backspace/delete should all behave naturally. Ghost aims to not trip you up when you are writing.

All common formatting shortcuts like bold and italic are also in place, plus a few extended ones and these are documented here:

https://ghost.org/faq/using-the-editor/#markdown-reference

We're missing documentation for shortcuts not related to formatting and I had thought that was because we only supported obvious ones, and all our custom shortcuts for things like publishing had been removed because they tend to cause conflicts with various keyboard layouts for other languages.

However, I have just done a test and cmd-shift-p does in fact publish the post. It also updates an already published post. cmd-s will save a draft post, and also update an already published post. You should be able to swap cmd for ctrl on linux and this should be a viable workaround for this issue for now 🎉

We need to review our shortcuts and document the remaining handful of custom ones we have that are genuinely useful and making them easy to find.

As for GitHub vs forum, with these issues it's a tricky line. If there are genuine usability problems that we aren't aware of, GitHub is fine for these especially if as in these cases there are people willing and able to contribute solutions. In this case it was also extra fun because I'm not sure anyone even realised we still had a publish shortcut - I wouldn't have suggested the API if I had realised 🙈

[ndarilek]

Nice, thanks for figuring these out for me! In this case I didn't even think to try ctrl-s because that's a browser shortcut, albeit one not likely to get used here, so I expected that to save the current page to my local drive and not to actually save my post. Anyhow, still hoping to see a PR fixing the actual DOM positioning of the controls in the dropdown, and I think this should remain open until that lands upstream. But for now I'm good. My site is up, and I'm successfully adding/updating content. Thanks again.

[ErisDS]

Did the ember-basic-dropdown upgrade help with this?

[ndarilek]

Partially. There were two issues: 1. The button reported as only a button, not as a collapsed item. The ember-basic-dropdown PR addressed this, and I can now tell when the item is collapsed or expanded. 2. Apparently, and please correct me if I'm wrong, the component creates markup like this: ```<button>   Text of button   <div>     <button>Child button</button>   </div> </button> ``` And screen readers don't know how to handle that, because it doesn't really make sense for a button to have children. I think Marco submitted another upstream PR to fix this, and it did seem to work in the demo I tried. If it hasn't been merged yet, maybe a group effort to push it forward would be in order? :) Happy to lend my voice to that effort.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[MarcoZehe]

This issue is still present in current Ghost and requires a PR to an upstream component that I submitted in May, be merged.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.