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

Draft: Check against APA FAST Review Checklist #222

Open
21 of 30 tasks
bkardell opened this issue Feb 26, 2024 · 0 comments
Open
21 of 30 tasks

Draft: Check against APA FAST Review Checklist #222

bkardell opened this issue Feb 26, 2024 · 0 comments

Comments

@bkardell
Copy link
Collaborator

bkardell commented Feb 26, 2024

MathML first became a REC in early April 1998. It was the first XML vocabulary, in fact.. MathML 3 was last made a REC in April 2014. However, large segments of this were unimplemented by any browser. Much of it was unaligned with the CSS or DOM standards that came later. It didn't have web platform tests for any of it, as it left most of the actual rendering entirely to UA's. MathML-Core, then is an effort to practically align MathML with the platform and what has managed to get implementation, and help achieve a good baseline. There are implementations of most of Level 1 basics in each of the browser engines already, and MathML-Core (and MathML-AAM) will help them align interoperably, in-line with HTML, DOM and CSS.

If technology allows visual rendering of content

It is DOM and CSS, it has an AAM. The only potential gotcha here is that linebreaking is unspecified in L1.

  • There is a defined way for a non-visual rendering to be created.
  • Content can be resized.
  • Luminosity and hue contrast can adapt to user requirements.
  • Text presentation attributes can be changed.
  • Visual presentation of pointers and cursors can be adjusted.
  • Changing content presentation does not render it unreadable.
  • Technology does not allow blinking or flashing of content, or provides a feature for users to quickly turn it off or permanently disable it.
  • It is possible to make navigation order correspond to the visual presentation.

If technology provides author control over color

It is DOM and CSS, I am checking some of these boxes because there isn't anything particularly special here with regards to color.

  • There is a mechanism for users to override colors of text and user interface components.
  • [ x] There is a feature for authors to define semantically available "color classes" that users can easily map to custom colors, and give preference to this vs. coloring objects individually.
  • There is a feature for users to choose color schemata that work for them.
  • The foreground and background color of an object can be reported to the user via AT.
  • There are ways to set foreground and background colors separately for all objects.
  • Compositing rules for foreground and background colors are well defined.

If technology provides features to accept user input

Level 1 does not, except insofar as authors can embed foreign content, which is just HTML or SVG and should be covered by those specs, not this one.

If technology provides user interaction features

Level 1 does not, except insofar as authors can script or embed foreign content, which is just HTML or SVG and should be covered by those specs, not this one. There are no interactive roles that apply in L1.

If technology defines document semantics

I am checking some of these boxes because it doesn't interfere with HTML, it can be embedded in HTML, and these seem like they are more about HTML. It is integrated with the HTML parser, in fact.

MathML Core does allow some attributes that are still being refined for the full MathML 4 spec. These attributes allow for disambiguation of speech (e.g., $(a,b)$ can be spoken as (among other things) "the point a comma b" or "the open interval from a to b"). The actual speech however will ultimately be determined by the AT that reads the MathML and the specification of these attributes are not part of the MathML Core spec.

  • Authors can title Web pages.
  • Authors can title sections of content.
  • Authors can clearly indicate the target of a hyperlink and function of a control.
  • Authors can indicate content language, for the page as a whole and for blocks of content.
  • Authors can support understanding of abbreviations / acronyms / initialisms, idioms, jargon, etc.
  • Authors can support correct machine pronunciation of ambiguously spelled terms (e.g., in the phrase "I am content with this content" there are different correct pronunciations of the lexeme "content").
  • Authors can identify regions of content, particularly the "main" region.
  • Declarative mechanisms (that have accessibility semantics pre-defined in the spec) are used to implement technology features whenever possible.
  • There are unambiguous ways to express relationships between units of content, such as object nesting, ID referencing, etc.
  • Prefer structural semantics to presentational semantics.
  • When providing presentational semantics, they can be easily mapped to structural semantics, e.g., to support restyling or meaningful exposure to accessibility APIs.
  • Support a comprehensive set of authoring use cases to minimize the need for alternative content. (e.g., don't make authors resort to text in images to get the style they want).
  • Semantics allow precise and replicable location information in the document to be determined.
  • Semantics exist to convey meaning that is commonly conveyed via presentation.

If technology provides time-based visual media

It does not

If technology provides audio

It does not

If technology allows time limits

It does not

If technology allows text content

MathML allows text in its leaf elements (mi, mn, etc). The spec itself is about non-linear display of that text as math notation.

  • Authors can define non-text alternatives for text content.
  • Authors can define non-text alternatives for non-text content.

If technology creates objects that don't have an inherent text representation

It does not

If technology provides content fallback mechanisms, whether text or other formats

....?

If technology provides visual graphics

It does not

If technology provides internationalization support

  • Accessibility features can be internationalized to the same degree as other features

If technology defines accessible alternative features

The root math element allows for an alttext attribute. The idea is that this can provide a fallback for MathML consumers that are not able to convert the MathML into text. It is meant to be a fallback as AT can often provide a better textual rendering based on the needs of the user (one size does not fit all).

If technology provides content directly for end-users

It does not

If technology defines an API

It does not

If technology defines a transmission protocol

It does not

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