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

Add an 'alt' attr to MathML elements that can take href #206

Closed
NSoiffer opened this issue Apr 3, 2020 · 8 comments
Closed

Add an 'alt' attr to MathML elements that can take href #206

NSoiffer opened this issue Apr 3, 2020 · 8 comments
Labels
accessibility Issues related to improving accessibility

Comments

@NSoiffer
Copy link
Contributor

NSoiffer commented Apr 3, 2020

As pointed out in https://github.com/mathml-refresh/mathml/issues/125#issuecomment-606595796, WCAG requires all links that can't be determined from the link text alone to allow for alt text so people know the point of the link. In general in MathML, the link's purpose will be clear because it will be on a leaf element or an mrow (likely the first instance of that specific token or mrow) and will be a definition or explanation of the function, notation, etc. Hence it likely won't need alt text. However, since someone may use the href for some other purpose (side commentary, problem solution, ???), alt text should be allowed.

On the other hand, WCAG also has an "out":

... except where the purpose of the link would be ambiguous to users in general.

So maybe we don't need to add it. I'm filing this issue to open discussion on it...

@NSoiffer NSoiffer added accessibility Issues related to improving accessibility MathML 4 Issues affecting the MathML 4 specification MathML Core Issues affecting the MathML Core specification need specification update Issues requiring specification changes labels Apr 3, 2020
@davidcarlisle
Copy link
Collaborator

alt seems the wrong attribute here, its use with html <img> (and mathml <math>) is as an alternative to showing the main content in-place. mathml href is like html href on <a> which doesn't have an alt attribute. The WCAG document you refer to doesn't say <a> should have an alt attribute just discusses the link text, which for <mi> is similarly the content surely?

@NSoiffer
Copy link
Contributor Author

NSoiffer commented Apr 4, 2020

Note: WCAG is technology agnostic, so doesn't say anything about HTML in particular.

The general idea of that WCAG criteria is that someone should know the purpose of the link. I think in HTML, people use "title" to do that when the content doesn't give that info. Or if the content is an image, then you add 'alt' to the image tag.

The standard recommendation is to make where the link goes clear based on the text. With math, that's not really an option -- the math is what the math is and you can't/shouldn't change that just because you want to link to something. So the "ambiguous to users in general" case may well apply. Basically, this clause says that someone using AT is no more disadvantaged than someone who doesn't use AT, so it isn't an accessibility issue (for text, it would be an example of poor authoring/wording).

@davidcarlisle
Copy link
Collaborator

Note: WCAG is technology agnostic, so doesn't say anything about HTML in particular.

yes, but when applied to HTML they didn't lead to a change of the language, adding alt= to <a href but rather to author guidelines to use meaningful link texts and/or aria attributes (or possibly title) and <mi href is same. alt in html is only used in places where the linked resource is displayed inline, not in links that require author interaction, so I think it would be confusing/wrong to add it to mi.

mi already allows aria and a mathml <semantics> attribution so I think it is more than covered already, but if we want to add another more concise attribution attribute we should follow the model of <a> not <img> and add title or other attributes accepted by <a>.

@faceless2
Copy link

I raised the original comment and suggested "alt" But for what it's worth I agree with David on "title". If href can be used on every element, the corresponding attribute clarifying the link purpose must be universally applicable too. "title" seems like a better fit than "alt", not least because it's universality is familiar from HTML.

I don't think you can always rely on the link purpose being clear from either the link text or the general context - as well as jumping to a proof or commentary, consider also links to footnotes with link text like †, or JS functions that hide a row of an equation, or reveal the value of a variable, or display a popup.

@davidcarlisle
Copy link
Collaborator

davidcarlisle commented Apr 4, 2020

@faceless2 but in mathml3 you can already do

<semantics>
<mi href="example.com">*</mi>
<annotation encoding="text/plain">this is a link for a footnote that goes to the example.com website that says something</annotation>
</semantics>

so the proposal is only about adding a more compact syntax using an attribute for the simpler cases, not about adding functionality. I don't object to that but it shouldn't be called alt as the usage for alt in html is quite different.

@NSoiffer
Copy link
Contributor Author

NSoiffer commented Apr 6, 2020

I agree 'alt' is not appropriate. 'title' is better, but @davidcarlisle's pointing out that semantics is an existing, albeit long winded alternative is a good reminder.

@fred-wang
Copy link

cc @joanmarie @asurkov

@NSoiffer
Copy link
Contributor Author

Discussed at Aug 17 meeting. @bkardell felt this isn't an issue for MathML and is really one for AAM, noting that MathML Core Level 1 doesn't have links so this is no longer relevant. Consensus is to close the issue.

@NSoiffer NSoiffer removed MathML 4 Issues affecting the MathML 4 specification MathML Core Issues affecting the MathML Core specification need specification update Issues requiring specification changes labels Aug 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility Issues related to improving accessibility
Projects
None yet
Development

No branches or pull requests

4 participants