Meeting minutes
Export - 7 - Table Structure elements
zkinsey: /giBraking the structure elements into the different export groups, currently 16
… For tables, we'r almost ready for structure table elements
… For table headers with scope is set to both, wwe are unsure what an analogous aria role would be, or if this is going to require something else
spectranaut_: Can you explain this?
Roman: This is specific to PDF, HTML doesn't have that
… We'll need to invent something new
spectranaut_: Is there an example of a PDF where scope is set to both?
JamesC: Usually the top left column
Zaak: But you could have sub tables within tables, where one row would apply to a number of rows inside the column
… It can occur on the x axes of the table
… Common in banking or investment tables
… Header identifying a stock trade, but then there's other headers that also apply
jcraig/gi: Worth considering in the context of treegrid as well
spectranaut_: Do existing mappings ffor Windows have some concept? What does Adobe currently do?
Roman: Currently they expose the value of the scope attribute, AT decision whether they make something meaningful
… NVDA doesn't announce anything I'd say, but I may be wrong
<jcraig> s/Zak /zkinsey /gi
Zaak: If a person is inside of a cell they're supposed to be able to ask what it is
spectranaut_: What do you think for AXAPI?
jcraig/gi: I don't remember if it's supported; not common... possibly not in any Apple-developed app. Possibly in Numbers.
spectranaut_: From a mapping perspective, you have to start with what's available but you could advocate for new data within the API
… IF you just expose it with one of the two directions, would it be obvious at least what's going on?
Zak: There's going to be multiple structure elements that won't be one-to-one mapping
… New API data may be a longer process. My question is what we can do in the short term
… What do we want to say in that table?
spectranaut_: For mappings you are not satisfied with there can be some * or some link to a note that says that mapping will evolve
jcraig: Maybe an editorial note or TBD
Roman: Sometimes we use scope as a flag. We sometimes have column or row.
spectranaut_: That concept doesn't exist in ARIA because it doesn't exist in accessibility APIs
spectranaut_: Even if it's not good mapping, some advice is welcome for people not to do different things
Roman: We may want to map it to column officially for implementers to have a common understanding
spectranaut_: Sometimes you waant to be very specific, others it's up to the PDF author to decide whatever is more important
Roman: We cannot do that, because in our standards we need to be very accurate and we need to follow "both"
<Zakim> Daniel, you wanted to react to a previous speaker
<Zakim> jcraig, you wanted to respond to Roman after Daniel and to disagree with spectranaut_ about AAM editors "suggesting" API mappings directly to engine vendors
Daniel: This one in particular is critical for tables to be useful. Others may not be as critical, research is desired
jcraig: We may want to take a "pick and choose" approach to decide waht to advocate for to the platform API owners
… But the AAM list should be a complete list.
… The prerrogative of the API owner should be to decide what to do if there's no mapping
spectranaut_: You don't wwant someone to put this as table cell because there's no both.
… No perfect solutions, but there can be wrong solutions
… It should be a header element
… In some cases we do need a fallback
zkinsey: Editorially it needs to be clear that we're working on this, but until that happens, a fallback of either row or column should be used and then let them choose at their discretion
… I see your point that this shouldn't be ignored
Alphabetize the AAM entries based on PLSI name
Daniel: There's already a PR for this, which is linked to the issue. It's now ready for review