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

Support STEM accessibility #1832

Closed
nvaccessAuto opened this issue Oct 14, 2011 · 2 comments
Closed

Support STEM accessibility #1832

nvaccessAuto opened this issue Oct 14, 2011 · 2 comments

Comments

@nvaccessAuto
Copy link

Reported by kevinchao89 on 2011-10-14 10:18
Unfortunately, accessibility of science, technology, engineering, and math content (textbooks, assignments, exams, etc.) for students, professors, researchers, etc. are all very difficult. This is because of a variety of things that are lacking.

All of the following MUST be met in order for STEM accessibility:

*proper speech output: NVDA to work with MathML, LaTex, an Accessible SVG. Must be fully understood, ingested, and output via speech in a effective and efficient manner. MathML and LaTex will open the doors to formulaas, equations, etc. for math, science, and engineering to be rendered in a very accessible and usable format for speech output. Accessible SVG is an area that is lacking across the board, but has great benefits for STEM graphs, charts, figures, models, etc. to be conveyed in a very powerful and functional speech output format, but it must be implimented properly.

  • Braille output: full Nemeth Math Braille code support, understanding, processing, and outputting all the formulas, equations, and all STEM content in tactile braille output.
  • Braille input: Ability to use braille keys to input Nemeth, for it to be understood, and back-translated into the print-equivalent.
@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2011-10-14 10:39
A few points:

  • NVDA should probably not work directly with MathML/!LaTeX code displayed in text. If a sighted user sees MathML/!LaTeX code, a screen reader should not translate that into math. Otherwise, the screen reader user is seeing something different to the sighted user. Instead, when a sighted user sees visual math, the screen reader should speak/braille math.
  • None of this can be done without browsers/editors (whether they be general purpose applications like web browsers or something more specific to STEM) exposing this content through standard accessibility APIs. Unfortunately, there is currently no standard for this at all, so this is a major roadblock.
  • It is not just a matter of speaking of brailling the STEM content. The way in which the user interacts with the content also needs to be considered. There needs to be some sort of cursor, but this raises some problems:
    • Reviewing character by character does not make sense for math, since the concept of a character is not really applicable.
    • As far as I know, none of the current braille translation libraries have a concept of a cursor for math. That is, they take some math code and translate it into braille, but after that, you can't identify which part of the code a given braille cell corresponds to and vice versa.
    • How do you handle synchronisation of braille and speech for math?
  • As for braille input, I don't really know how this could be done. There's no standard way to type math on a computer, so it's not just a matter of translating braille into keystrokes. Again, a screen reader should probably not be working with markup here, but something more abstract.

In short, none of this can be done without major work across the entire accessibility industry.

@dkager
Copy link
Collaborator

dkager commented Jul 5, 2017

I think this can be closed:

  1. The scope is too broad, spanning the entire STEM field and many different technologies.
  2. There is no mention of solutions to the stated problems.

For reference, MathML is now supported. See #4673.

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

3 participants