You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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).
The text was updated successfully, but these errors were encountered: