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

Seems Contrary to OpenAAC Project it is Promoted Under #1

Open
nat42 opened this issue Mar 24, 2022 · 0 comments
Open

Seems Contrary to OpenAAC Project it is Promoted Under #1

nat42 opened this issue Mar 24, 2022 · 0 comments

Comments

@nat42
Copy link

nat42 commented Mar 24, 2022

On the OpenAAC website this (AAC Shim) seems to be described as enabling any website to support AAC software without mention of CoughDrop; but it would seem to be CoughDrop specific and come with no suggestion as to how or why this Javascript code might be usable for the purpose described with other vendor's software.

If this is actually CoughDrop specific, with no reference implementation and an API based around a design specific to the needs of CoughDrop, I would suggest that this would seem to me to be contrary to the stated goals of OpenAAC such as being against "business practices that interfere with AAC user freedoms such as vendor lock-in are inappropriate" (at the very least by failing to disclose that this is CoughDrop specific and instead lead a casual reader to expect that they might support a broad range of AAC vendor software implementying AAC Shim)

As someone with some front end experience, I also wouldn't want to use this beyond perhaps calling aac_shim.map_to_mouse_events(), the idea of hardcoding a layout to specific pixels or percentages, and then describing that positioning with Javascript seems like something someone might have expected for an IE5.5 only webpage decades ago!

Given the push towards a simplified interface with larger button areas, my niave thinking would be that I'd want to try redirecting requests towards an AAC specific resource (assuming the AAC browser might allow users to opt out of such redirect) and I'd expect something like the "prompt" parameter of "add_target" to instead come from reading like an Aria-label attribute on the element (as much as possible I'd think you'd want to overlap AAC support with existing web accessibility).

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

No branches or pull requests

1 participant