00:00 | <Seirdy> | if a figure containing a figcaption isn't allowed to have any other roles but I want to annotate the figure as a "doc-example" using DPUB-ARIA, would enclosing the figure in a <div> that has the doc-example role be acceptable? |
00:03 | <Seirdy> | semantics are tricky; it's hard to show that something is an example and has a caption. but on really long documents with lots of figures, being able to skim by filtering figures (esp. when reading linearly, eg with a screenreader) should be helpful. |
01:22 | <aja> | Seirdy, noticed the same thing...DPUB-ARIA table says you should be able to use it on figcaption; specs are inconsistant. |
01:30 | <aja> | also noted some some auditing tools don't like page-header or page-footer on section element, as DPUB-ARIA table indicates. perhaps wanting them to be on header or footer elements instead? |
04:33 | <Seirdy> | also noted some some auditing tools don't like page-header or page-footer on section element, as DPUB-ARIA table indicates. perhaps wanting them to be on header or footer elements instead? |
04:34 | <aja> | iirc, aXe ??? |
04:36 | <Seirdy> | ugh, ofc it's aXe |
04:36 | <aja> | seem to recall it being fixed in pre-lease now |
04:37 | <Seirdy> | yeah the very latest release fixed a few dpub issues (finally making the skipping of doc-endnote a non-error), didn't know about this tho |
04:38 | <aja> | may be confused....been a few months since doing related testing |
04:39 | <Seirdy> | maybe by Q4 2023 we'll be freed from the outdated audits of aXe-4.3 and earlier, as all the meta-auditors finally bump their dependencies |
04:42 | <Seirdy> | for now tho, would it be a good idea to wrap the figure in a div with role=example ? |
04:49 | <aja> | i guess...never bothered since mine were multiple font samples in a details element in a colophon (non-landmark) section |
17:14 | <mgaudet> | Domenic: Sort of related to the completion values conversation in Streams: One thing that's not clear to me is how strong we should take completion value annotation. For example, in ReadableByteStreamTee, 15.2 close steps, ReadableByteStreamControllerClose is annotated with a So I'm left wondering if this is a specification bug (and wondering what it means if close steps throws, as they're not annotated one way or another completion record wise), or if this is a dynamic assertion that this should never throw here, and so I should be able to assert that. |
17:17 | <mgaudet> | (This matters because of the signature changes error-handling brings, and how far you have to propagate these errors) |
18:42 | <Domenic> | mgaudet: that is asserting that that particular call cannot throw, because of how we've set things up. Often those kind of mismatches occur when things can throw because of web developers doing something weird, and if the spec calls something, it is asserting that it is not doing something weird. |
20:20 | <mgaudet> | mgaudet: that is asserting that that particular call cannot throw, because of how we've set things up. Often those kind of mismatches occur when things can throw because of web developers doing something weird, and if the spec calls something, it is asserting that it is not doing something weird. |
20:24 | <mgaudet> | Honestly... I think playing with this makes me less convinced of the value of the completion value assertions; i.e. I think I'd still see value in ? Algo in the spec, but ! Foo doesn't align with the reality of implementation when you factor in all the un-specified throw locations that actually exist in implementation. |
20:25 | <mgaudet> | Which makes me sad... but it's true. |