Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessible drag-and-drop #459

Open
ndarilek opened this issue Dec 28, 2015 · 41 comments
Open

Accessible drag-and-drop #459

ndarilek opened this issue Dec 28, 2015 · 41 comments

Comments

@ndarilek
Copy link

As a screen reader user, I find myself occasionally needing to reorder lists and cards. Looking at the code, I think drag-and-drop is supported but I'm not sure in which contexts this is true.

An accessible DND implementation is a bit complicated and I'm not immediately sure how to accomplish it. However, maybe some "Move up/Move down" arrows with aria-labels would be a good first implementation. They could be located in the heading for the card/board, and hidden with Bootstrap's sr-only style if you didn't want them visible (I know Bootstrap isn't being used here but you could look to its sr-only definition as an example of how to reveal something only to screen readers.)

@mfaure
Copy link

mfaure commented Dec 28, 2015

Wordpress (4.4) has a rather good accessibility implementation of drag-n-drop (in its backoffice)

@mquandalle
Copy link
Contributor

I think one solution is to provide an alternative way of moving cards/tasks that doesn’t involve drag and drop. Trello has an option in their card menu to “Move a card” which provide a form where you can select a board, a list in this board, and a position in this list and press “Move”. Drag dropping cards is fun, but this more classical form would be useful for screen reader.

@ndarilek
Copy link
Author

ndarilek commented Dec 28, 2015 via email

@mquandalle
Copy link
Contributor

You don’t really need to memorize the actual position since it is the default value of the <select> field. Basically once your browser focus on this field you can press twice and press Enter to move the card up above the two previous ones.

I haven’t see Wordpress 4.4 DnD neither.

@ndarilek
Copy link
Author

ndarilek commented Dec 28, 2015 via email

@mquandalle
Copy link
Contributor

Yes with this solution all board selection, list selection, and position selection would be implemented using <select> fields (or maybe enhanced select-like HTML components, in which case we need to be careful about accessibility support).

@bnicot
Copy link

bnicot commented May 20, 2017

any news about that ?

@mgifford
Copy link

Just wanting to check in to see if there have been any updates since 2017 on this. None of the commercial tools out there have done a good job with accessibility. I think GitHub will be pretty good for this feature.

@xet7
Copy link
Member

xet7 commented Jun 13, 2021

@mgifford

Just wanting to check in to see if there have been any updates since 2017 on this. None of the commercial tools out there have done a good job with accessibility.

I think GitHub will be pretty good for this feature.

I don't know, is GitHub accessible?

@xet7
Copy link
Member

xet7 commented Jun 13, 2021

@mgifford

Also there is #2499 about Dragon speech recognition sofware. Do you know does someone still use that software?

Or what do people use for screen readers, etc accessibility?

I'm still complete novice on accessibility. I'm trying to learn.

@xet7
Copy link
Member

xet7 commented Jun 13, 2021

@mgifford

For current Wekan, it's done with Meteor web framework, both frontend and backend are done with Javascript. But it's not necessary to run all that Javascript at frontend browserside, I most likely change most Javascript to run serverside, and have frontend with optional Javascript only.

Current Meteor Wekan supported webbrowsers are here:
https://github.com/wekan/wekan/wiki/Browser-compatibility-matrix

There Javascript drag-drop, animations, etc currently in Wekan, but those could be done some other way when there is no Javascript at frontend.

@mgifford
Copy link

Lots of stuff here. GitHub has some accessibility features. Their kanban board has some big issues. It definitely doesn't meet WCAG compliance requirements.

Very cool about the grant! That's terrific.

This isn't a problem with JS. Having a fallback is nice, but that is kinda secondary issue. Most assistive technology works just fine working with the DOM. There are many reasons to build an HTML/CSS driven presentation, but I don't see accessibility as a big one for this.

GatsbyJS is also pretty solidly JS, and they might be able to find some material that you could draw on here:
https://www.gatsbyjs.com/accessibility-statement

I don't know many folks who use speech to text tools like Dragon. Apple now comes with Voice Control built in to their OSs. This is something that's going to be an issue for people with mobility challenges, but also folks who aren't able to type but want to interact with a device. Say you're using VR.

@xet7 start with https://accessibilityinsights.io/ eventually start looking at building with axe into your CI like GatsbyJS does. If you use Twitter, follow some of these folks https://github.com/joe-watkins/top-people-to-follow-in-web-accessibility

There is just so much available on GitHub projects too.

Meteor doesn't seem to have done a great job building in accessibility. React is making this a priority though https://reactjs.org/docs/accessibility.html

Hope this helps. We're also building out some resources here https://accessibility.civicactions.com/

@xet7
Copy link
Member

xet7 commented Jun 13, 2021

@mgifford

I do have remote access to Mac Mini M1, thanks to MacStadium: https://github.com/wekan/wekan/wiki/Mac

How should interacting in VR work, for it to be accessible?

@xet7
Copy link
Member

xet7 commented Jun 13, 2021

Related #337

@xet7
Copy link
Member

xet7 commented Jun 13, 2021

@mgifford

Meteor doesn't seem to have done a great job building in accessibility. React is making this a priority though https://reactjs.org/docs/accessibility.html

For frontend UI, Wekan currently uses Blaze. There has been new releases of Blaze, but I have not yet checked about Blaze accessibility features.

Meteor works also with other frontend frameworks. When creating new Meteor project, there are these alternatives:

$ meteor create
Usage: meteor create [--release <release>] [--bare|--minimal|--full|--react|--vue|--apollo|--svelte|--blaze] <path>
       meteor create [--release <release>] --example <example_name> [<path>]
       meteor create --list
       meteor create --package [<package_name>]

Options:
  --package     Create a new meteor package instead of an app.
  --example     Example template to use.
  --list        Show list of available examples.
  --bare        Create an empty app.
  --minimal     Create an app with as few Meteor packages as possible.
  --full        Create a fully scaffolded app.
  --react       Create a basic react-based app, same as default.
  --vue         Create a basic vue-based app.
  --apollo      Create a basic apollo-based app.
  --svelte      Create a basic svelte-based app.
  --typescript  Create a basic Typescript React-based app.
  --blaze       Create a basic blaze-based app.

@xet7
Copy link
Member

xet7 commented Jun 13, 2021

@mgifford

Looking at the links you provided, it's kind of too much to read. Do you have some examples what should be changed in Wekan, to make it accessible? And which ones of those recommendations and changes are necessary, for Wekan to be accessible enough? Is there someone that could test Wekan for accessibility? Like some actual user, that would be testing does something improve or not, and provide feedback?

@mgifford
Copy link

@xet7 accessibility is like security. You can make wekan more secure. You can make sure you are doing your basic due diligence to ensure that it is hard, or even very hard to exploit. Still, it will never be secure. How secure it will be totally depends on how vigilant the community of developers & users is. What culture exists around the software with regard to security.

Same thing with accessibility.

So don't aim to make it "just good enough". I suspect there's a long way before it could meet minimum EU government regulations for accessibility of public sites. Aim instead to make it a bit more accessible than it was previously.

Start with this tool https://accessibilityinsights.io as a simple browser extension.

Run it against your demo. Fix what you can.

@xet7
Copy link
Member

xet7 commented Jun 14, 2021

@mgifford

Thanks! I have looked at various accessibility info, and I'm slowly beginning to understand what accessibility means. Yes, it will take time.

@xet7
Copy link
Member

xet7 commented Jun 26, 2021

@mgifford
Copy link

This is a bit old, but might be some useful ideas here too https://www.drupal.org/node/2920006

@xet7
Copy link
Member

xet7 commented Jun 28, 2021

@xet7 xet7 pinned this issue Dec 21, 2021
@xet7
Copy link
Member

xet7 commented Dec 21, 2021

It seems that accessibility surveys at https://wekan.github.io did not yet have any useful responses.

But anyway, from some other community I got this real info how to implement accessibility.

Terminal text readable/speakable output: DOS/Windows/Linux

  • There are screen readers for most operating systems
  • There is JAWS for DOS at 11-minute mark of https://www.youtube.com/watch?v=bPW2S4fZMJY but JAWS is very slow on DosBox. There are some wishes to have Open Source alternative that would work in FreeDOS.
  • Screen readers automatically speak any text that gets output to the terminal. So it's OK to show some amount of text, and then menu options after that, what key to press next.
  • ASCII art is a problem: it's text, so screen readers speak it as it appears. So for example, we all know what :) means, but screen readers see it as "colon right paren", not "smiley". So any icons or smileys should be converted to readable text. As long as ASCII art is an optional feature that can be turned off, a11y is a non-issue for terminal apps.

TODO:

  • In some WeKan CLI terminal based prototype try to make text-based kanban working. Also PRs welcome.

Web: HTML only for screen readers

  • related WCAG and ARIA specs
  • screen readers can see HTML but not CSS, the importance of keyboard support and so on.

Here's a quick-and-easy way to test if your website or web app is accessible:

  1. Turn on your screen reader (every OS has one in settings).
  2. Power off your monitor.
  3. Unplug your mouse.
  4. Try to use your app.
  5. When you're done, run the browser extension "Axe", a great open-source tool by a company called Deque https://www.deque.com/axe/

TODO:

  • Try to add some fixes to WeKan that browser extension "Axe" recommends. Also PRs welcome.
  • Try making WeKan usable in Links/Lynx/ELinks etc text based browsers, with first some text that is speakable, then some menu options after that, possibility to use only keyboard etc.

@xet7 xet7 unpinned this issue Jan 19, 2022
@xet7 xet7 pinned this issue May 14, 2022
@xet7
Copy link
Member

xet7 commented May 27, 2022

Reading this about accessibility:
https://dev.to/abbeyperini/web-development-accessibility-f8i

Above article has link to this article, that mentions that Eric Meyer’s CSS Reset should not be used:
https://dev.to/colabottles/stop-removing-focus-2o7b

WeKan includes that Eric Meyers's CSS Reset here. When converting Stylus to CSS, those extra bullet points were because that CSS Reset was missing, so it was added back. UPDATE: Maybe newest CSS Reset does not have that focus code at all.
https://github.com/wekan/wekan/blob/master/client/components/main/layouts.css#L1-L57

Related to accessibility, and adding support for more browsers, when I tested at BrowserStack (that donated access to testing with various browsers to WeKan), Multiverse WeKan static test page example at https://wekan.team/test/ , screen readers at Windows and Mac did also correctly read emojis, and load page fast. That test page loaded fast also at Mojave #4529 . Test page did load and show correctly in all browsers, only problem was if browser did not support newest TLS. So I presume future of WeKan is to be more like Multiverse WeKan so that there is support for a lot of more browsers.

When at BrowserStack I tested Meteor WeKan Roadmap page loaded very slowly, many times it did not load at all, or showed Safari being unresponsive on some older macOS, etc.

@xet7
Copy link
Member

xet7 commented May 28, 2022

About many kinds of accessibility devices:
https://ericwbailey.design/writing/truths-about-digital-accessibility/

@xet7
Copy link
Member

xet7 commented May 28, 2022

About accessible routing, and what was found in various accessibility testing:
https://www.gatsbyjs.com/blog/2019-07-11-user-testing-accessible-client-routing/

@xet7
Copy link
Member

xet7 commented Jun 18, 2022

This article has some links to accessibility:
https://news.ycombinator.com/item?id=31785556

@xet7 xet7 unpinned this issue Jul 5, 2022
@xet7
Copy link
Member

xet7 commented Jul 14, 2022

@mgifford
Copy link

Yup.. Can make people visually sick. Visually Induced Motion Sickness (VIMS).

@xet7
Copy link
Member

xet7 commented Jul 28, 2022

This also about accessibility for blind:

https://news.ycombinator.com/item?id=32252732

@xet7
Copy link
Member

xet7 commented Aug 3, 2022

Smart glasses turn speech into subtitles, in real-time

https://xrai.glass

https://news.ycombinator.com/item?id=32320003

@xet7
Copy link
Member

xet7 commented Aug 11, 2022

@xet7
Copy link
Member

xet7 commented Aug 16, 2022

The impact of removing jQuery on web performance, and lightweight goverment website design system sthat is here https://design-system.service.gov.uk/

https://insidegovuk.blog.gov.uk/2022/08/15/the-impact-of-removing-jquery-on-our-web-performance/

From https://news.ycombinator.com/item?id=32480755 some comments:

ctrlmeta 44 minutes ago:

Has anyone noticed how all UK government websites like https://www.gov.uk/, https://www.nhs.uk/, https://tfl.gov.uk/, https://coronavirus.data.gov.uk/ have the same look-and-feel and the same UX? Are there more such examples of countries that have uniform UX for their government websites?

magnio 38 minutes ago:

Yes, this is an example of government design systems, which are becoming popular among developed countries:

@xet7
Copy link
Member

xet7 commented Nov 2, 2022

Hmm, I don't understand what is the point here?

@xet7
Copy link
Member

xet7 commented Jan 3, 2023

@xet7
Copy link
Member

xet7 commented Jan 3, 2023

accessibility1

@xet7
Copy link
Member

xet7 commented Jan 3, 2023

accessibility2

@xet7
Copy link
Member

xet7 commented Oct 16, 2023

@xet7
Copy link
Member

xet7 commented Oct 26, 2023

About Mobile-First/Mobile-Only:

But I do not know how this would affect WeKan, what improvements would be good? WeKan has mobile mode and desktop mode, and toggle drag handles.

Sometime maybe would be useful to add toggle mobile/desktop mode at mobile.

@xet7
Copy link
Member

xet7 commented Nov 25, 2023

From this article about HTMX:

Why does every article about htmx uses non-semantic HTML and has so much accessibility issues? I mean, most CSR app examples would use buttons here at a minimum. They wouldn't use forms most if the time but that less important because with broken/absent JS the app is just not there (blank page), but with htmx you're enhancing html and that means you just have a non-blank but entirely broken page.

I try to make WeKan more accessible.

@xet7
Copy link
Member

xet7 commented Dec 29, 2023

About accessibility:

https://news.ycombinator.com/item?id=38796582

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants