jasonjgw
commented
1 year ago Should there be a "support features of assistive technologies that facilitate the use of collaborative features" requirement? For example, if a screen reader has commands for navigating through comments or suggested changes, requiring the collaboration tool to support it might be reasonable.
However, these features are designed for word processors. So, for instance, they might not be appropriate to a collaborative source code editor.
sehollier
[Quoting from the COGA Task Force comment as submitted to the mailing list]:
I’m curious how screen reader users feel about having to use a new tool instead of the screen readers they are used to using? Instead of using their normal action keys, they have to use different ones when using a specific collaborative tool?
I’d like to see something in that document that talks about allowing users to use the options/tools/functions they are used to and not have to relearn something new. It’s talked about a bit in there but I feel it’s missing something.
If I want to read / comprehend a Google Docs, I have to download it to a Word document, which Google allows you to do, then open it up in Word to read with my tool. Which breaks the collaboration part because I can no longer follow what people are adding in real time.
Although what Jennie and I found out when working on the sub group, was that we could put a Word doc on Google Drive and open it in the browser or in Word directly if you have Google Drive synced on your operating system. You still loose some of the collaboration options but still better than download and upload versions like we did in the 2000s.
Something I’d like to see in the future is interoperability between editing tools. Content is content and the tool is just the user interface. I can see this maybe happening with markdown, but I think we are far from that.