- From: Neil Soiffer <soiffer@alum.mit.edu>
- Date: Tue, 30 Apr 2024 23:41:05 -0700
- To: "www-math@w3.org" <www-math@w3.org>
- Message-ID: <CAESRWkBKBV+_iA+fxez4GxwJGr6kN2sq_xUKWFTU0BC2Rp9BDQ@mail.gmail.com>
Attendees: - Neil Soiffer - Louis Maher - David Carlisle - David Farmer - Murray Sargent - Moritz Schubotz - Paul Libbrecht - Bert Bos - Deyan Ginev - Dennis Müller <https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-15#cp-md-0-regrets> Regrets <https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-15#cp-md-0-action-items>Action Items - *ACTION* DC will check Fred's changes in issue 103: percentage of minsize/maxsize <https://github.com/w3c/mathml-core/issues/103>. DC will do this before the core meeting on Monday. - *ACTION* Close core issue 238 <https://github.com/w3c/mathml-core/issues/238> - MuS discussed Native MathML rendering problems (core issue #229) <https://github.com/w3c/mathml-core/issues/229> This discussion will be continued. - Add a :structure (or :literal) property? (#492) <https://github.com/w3c/mathml/issues/492> Continue this discussion. - Clarify property use as descriptions (#493) <https://github.com/w3c/mathml/issues/493> Continue this discussion. - *ACTION* LM should see how screen readers like JAWS and NVDA interact with aria-label and aria-description. - *ACTION* DC can see if aria-description has other uses than screen readers? Could aria-description be used by AT for other types of readers? - *ACTION* NS: read about aria description and see if it is compatible with intent. - *ACTION* PL will look into seeing if JavaScript can determine where a screen reader is reading and if this could be used to give access information. <https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-15#cp-md-0-agenda> Agenda <https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-15#cp-md-0-1-announcements-updates-progress-reports>1. Announcements/Updates/Progress reports NS: There is a MathML core meeting on Monday. BK is looking for agenda topics. Please send him agenda suggestions. PL Ask about sanitizers which produce lists of safe MathML expressions. NS thought that sanitizers should be part of the core discussion. NS suggested that sanitizers be brought up in the core meeting. LM: The core meetings occur on the last Monday of each month, at the same Zoom link and time of day that the intent meetings use. PL has written to people about monetary symbols for our units discussion; however, they have not replied to him. <https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-15#cp-md-0-2-quick-review-of-action-items-from-the-last-two-weeks>2. Quick review of action items from the last two weeks - *ACTION* NS: will add the dyne (f) and erg (E) to issue 475 <https://github.com/w3c/mathml/issues/475>. NS added dyne and erg to issue 475. Based on the MKS Wikipedia page, NS believes that the symbol for dyne is dyn, and not f, and that the symbol for erg is erg and not E. If anyone knows different, please put a comment into the issue. - *ACTION* DC will reach out to Chinese TeX groups and ask them about units used in Asian languages. Do they see these symbols in publications? From Deyan Ginev to Everyone: Chinese units: https://en.wikipedia.org/wiki/Chinese_units_of_measurement - *ACTION* NS will reach out to his Chinese MathCAT contact about units. NS did this. He was told that the Chinese use SI units in their publications. NS: The two Chinese-related action items are closed. - *ACTION* DC will check Fred's changes in issue 103: percentage of minsize/maxsize <https://github.com/w3c/mathml-core/issues/103>. DC will do this before the core meeting on Monday. - *ACTION* DC should reply that neither TeX nor Word support asymmetric stretching. DC will make a comment about this in this PR. This comment will need updating due to LuaTeX and Word supporting stretching. DC has made his comment. Since LuaTeX does not affect stretching, DC' does not have to add any further information to his comment. This action item is closed. - *ACTION* DC will open an issue on stretchiness (???). From Deyan Ginev to everyone: Unicode TR25. NS: We already have an issue on stretching core issue 238) <https://github.com/w3c/mathml-core/issues/238> which we will consider next. NS: The operator dictionary also consider stretching. NS: Consider this action item completed. - *ACTION* NS: Mention that it's not changed, and that the 90% would be a fine way to implement it. This is for core issue 238) <https://github.com/w3c/mathml-core/issues/238> NS wrote: Small update from the MathML Full meeting on 18/4/24: @davidcarlisle pointed out that \delimitershortfall=5pt is probably irrelevant on the web and that only adding a fixed 90% of the target step to the vertical stretchy algorithm in the spec is needed to make the layout similar to TeX. It appears that \delimiterfactor is almost never changed in TeX and so there is no need to expose that as something that can be changed. DC pointed out that the 5 points is really not relevant in the web world. NS: said that DG and DC commented that no one ever changes the 90%. NS: I think it's delimiter or shortfall or whatever it was called. NS: Hard coding the 90% into the spec would be a good thing to do. *ACTION* Close core issue 238 <https://github.com/w3c/mathml-core/issues/238> - MuS discussed Native MathML rendering problems (core issue #229) <https://github.com/w3c/mathml-core/issues/229> MuS has noticed that the parens are a little high. They don't want to go down to the baseline. MuS needs to make some codepens to show his problem cases. MuS: It works well in MathJax. We should strive to match MathJax. NS is waiting for Fred to make some comments on this. NS will create several issues out of the problems in issue 229 so that they can be delt with individually. This is not an action item for NS. This discussion will be continued. <https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-15#cp-md-0-3-discussion-continued-from-last-week->3. Discussion continued from last week: - Add a :structure (or :literal) property? (#492) <https://github.com/w3c/mathml/issues/492> NS: Should we add a structural property? NS: We have two issues: does it make sense to have a property, if so, what should it be called? NS likes having a property so that you do not have to be literal for everything. DG: The "structure" property would tell the AT to speak the exact presentation structure/layout of an expression. NS would like to call the property "structure". DG does not like the name "structure" because higher mathematics has a concept called structure. The term "function" has the same issue in that the word "function" has a mathematical meaning. DG: You want a short but clear name for your property. For example, your property might be called "by columns" meaning that the table should be read by columns and not by rows. Do not say just "columns" but say "by columns" making your intent clearer. PL: We could use the term "verbatim". NS: We would be trying to read the structure of the term. We would not say "power", but we would say "superscript". Instead of mfrac, we would use the term "over". From Dennis Müller to everyone: "notational" maybe? That seems to fit that for which it's intended? NS: In issue 433 <https://github.com/w3c/mathml/issues/433#issuecomment-1420212046> NS discussed three levels of defaults to guide speech. they were: - legacy (default) -- AT is free to apply any heuristics they want - structure -- speak the structure - common -- speak the common interpretation in lower-level math. NS: You do not always have to read the structure: read x dagger instead of reading x superscript dagger. DF has said that he does not wish to make people work to say the obvious. DG: How about "use columns" DC: How about "by structure"? PL likes "by notation". PL Thinks the word structure is semantic. DG suggested read columns, read structure, read legacy, or layout. NS: How about syntactic. DC: Does not think layout is what a working mathematician would use. We should not over think things. NS: I am a little leery of using "by notation" because binomial coefficient notation is a notation. If I say by notation, then aren't I really saying I put in a binomial notation, you should read it as a binomial, when, in fact, literally, you want to be saying that it is a parentheses and something for what to do when there's no fraction line. PL: The reason I like "by notation" is that "structure aims at being semantic and intent wants to get away from being semantic. NS: Consider |x|. This could mean absolute value, a matrix, a determinant, or a notation for cardinality. The word "by notation" has a semantic aspect to it whereas "structure" tells you what is there. PL: Structure is the way to arrange things, and syntax is the way to input things. DG likes the word layout which implies the layout of the presentation tree. NS: How about tree? MuS: Tree is a computer-science term. Users may not know what it means regarding mathematics. DC likes layout, but he is not sure an ordinary practitioner would ever consider it in this context. BM: You were looking to do something slightly unnatural by trying to read the raw MathML. DC: Mentioned "read tree". BM: "Raw" is tempting. NS likes "tree". Using "tree' gets you away from the semantics. You are just reading the tree. NS: What should happen if it's structure. Leaf tags speak their comments or contents. There are exceptional cases for the weird ones such as square root (you could say radical symbol and then radical symbol with index for mth root), primes and degrees, m over (which could be bar, hat, and carrot). Instead of bar over x you would say x bar. DC: X bar could mean "mean" or "complex conjugate". NS: With "structure" NS wants to get lists of suggested ways to speak things. not strictly literal or descriptive. continue next week. - Clarify property use as descriptions (#493) <https://github.com/w3c/mathml/issues/493> NS: Should we use aria-description instead of using the property as a description? NS thought that DG said: we were told by the ARIA group to figure out our own means, but NS thinks that was really a discussion about aria-label. NS: The aria-label is what gets read normally. If we want to use aria-description, see how this fits in with MathML. NS: Has anyone read the aria-description information? NS: We have a more complicated system than aria-label. NS: If we want to go with aria-label, then we need to think hard about if it fits in with MathML. NS: Has anyone read about how aria-description works with MathML? NS to LM: When using screen readers, and you encounter descriptions, if you hear a label, is there a command to get more details? LM: Yes, but I do not know if aria-description is the source of that additional information. *ACTION* LM should see how screen readers like JAWS and NVDA interact with aria-label and aria-description. From Deyan Ginev to everyone: 2021 demo of using ARIA description with MathML 3 : https://hackmd.io/DUYgVDRtR9i08-sS7nlUpQ NS wondered if aria-description had other uses outside of screen readers, for example would aria-description be used for popups? PL: We do not know if there is any standard practice for providing various levels of descriptions. PL: It seems that the only thing we can do as a mathematical group is to provide spaces for descriptions of various details. *ACTION* DC can see if aria-description has other uses than screen readers? Could aria-description be used by AT for other types of readers? DC: NVDA has some options for aria-description. does aria description have any uses other than screen readers? - *ACTION* NS: read about aria description and see if it is compatible with intent. PL: Can we use aria-description to enrich dynamically interactive text? NS: Aria description is not meant to be interactive. it is static. It might be used to expand the description of a figure. It can not be used to query something. DG: It would satisfy me if we could use some kind of description in MathML. DG: If we have specific ARIA questions, we can open new issues in the ARIA Repository and ask them. NS: Let us discuss this some in our group, and if we still have questions, we can post questions to the ARIA group. DG: Do I posted the link in the chat about 2021 demo I made with aria-description in MathML 3, where you required a little bit of finagling? I think my demo was using chromevox at the time, because I didn't have any other activity to the chrome screen reader And if you would arrange the attributes just so, and fool the screen reader into entering the MathML, you can send it down an interesting path, using ids. PL: While thinking about all these possible mathematical augmentations, it seems to me that the nice feature we could make for this community is to have a JavaScript API. NS: If we do a JavaScript API, it has to go into core. Probably core level 2. You should come to the core meeting to discuss this. MuS: What methods would you add to JavaScript? DC: The mathematical suite. PL: It would be useful if the JavaScript knew where the screen reader was speaking. Possibly we could then get rid of any aria-description. We could just put this into data. NS: If we could get this kind of thing for text, then it would be easier to extend that to Math. *ACTION* PL will look into seeing if JavaScript can determine where a screen reader is reading and if this could be used to give access information.
Received on Wednesday, 1 May 2024 06:41:17 UTC