Meeting minutes
<wendyreid> preent+
TPAC 2022 Attendance
wendyreid: W3C exploring idea of holding TPAC in person this year in Vancouver, BC, Canada
… they've asked all chairs to gauge interest with their wgs
… probably impossible to know at this point if people will go, it would be in September
… some employers are not allowing corporate travel right now
… not sure what situation will be like by September
dauwhe: I hear rumors that they are dropping testing requirements for vaccinated people soon
… if at all possible I would go to in person TPAC
… given safety, etc.
wendyreid: so if everything makes this possible, what is the interest in holding in person TPAC meeting?
… it would be a hybrid meeting, by the way
… i.e. same as during the before times
… with simultaneous in person and online participants
duga: assuming all the above, my interest is high
shiestyle: not sure about the situation at my company, but I will discuss with our JP members in Japanese
… [in Japanese]
… toshiakikoike says that it would be difficult for him due to health and the covid policy at his company
… MasakazuKitahara says it would also be difficult for him, given the current situation
MURATA: i'm thinking of going to Italy this year for DAISY conference, I am not prohibited from going. But what will be the topic of the meeting there?
wendyreid: still TBD
duga: TPAC is happening either way, we're just deciding whether there will be an in person component
MURATA: in my experience hybrid conferences don't work as well, do you agree?
wendyreid: it's definitely harder, but we've done it for 2 years before covid
… we may change the time, i.e. have shorter sessions
… maybe 2 mornings, or 2 afternoons, depending on what works for everyone
… and a Pacific time zone makes it hard to coordinate meeting times with EU
… but we will do our best for everything, and timezones are being considered
… they may just be deciding whether they want to keep their reservation at the conference facility
dauwhe: do you have what you need to report back?
<dauwhe> https://
wendyreid: yes, I think so!
Page Progression Direction
dauwhe: I was a little puzzled by language in the spec around this
… there may be a clash of terminology, i.e. page-progression-direction attribute from the package doc, CSS's own documentation about page progression, etc.
duga: I think there was some proposed text at the end of the discussion
wendyreid: "if page progression direction has value other than default, RS must ignore page progression computed from the content"
dauwhe: if you don't put page progression direction in package, but you obviously have rtl content then it seems strange to say that the RS can't figure that out
… so I would support the proposed text
MURATA: sounds reasonable to me
<wendyreid> Proposed: Adopt Brady's suggested text in issue 1483, close issue 1483
<dauwhe> +1
<wendyreid> +1
<shiestyle> +1
<duga> +1
<toshiakikoike> +1
+1
<MasakazuKitahara> +1
RESOLUTION: Adopt Brady's suggested text in issue 1483, close issue 1483
FXL Limitations
wendyreid: not a lot of discussion on these, but they are still open, so we want to mention
… gpellegrino did review of a11y documentation last year
… he raised 2 issues specifically about FXL a11y
… one is about there being limitations on FXL a11y right now, not able to make fully accessible FXL document right now
<dauwhe> https://
wendyreid: other one is about accessibility and orientation, there will be a note in best practices that blocking orientation can impede readability
… if no comments, both gpellgrino's comments will be reflected in note
dauwhe: my understanding is that the problem which cannot be avoided in making FXL accessible content is that font size is fixed
… is there accessibility metadata around there?
wendyreid: i think so, but I can't recall specific accessibility hazard text at the moment
… but yes, inability to modify text size, font face
… we will be mapping some of the statements in the best practice note to WCAG - one of these is about scrolling, i.e. having to scroll both horizontally and vertically to read content if zoomed in
dauwhe: i could definitely make an FXL that doesn't specify fonts, but not sure if RS would allow user to choose a font
duga: no, the whole point of FXL is that you're not supposed to change that
dauwhe: does the CSS positioning spec say that you can use these things to make inaccessible documents?
wendyreid: there is an accessibility feature call display transformability, but not corresponding accessibility hazard for no display transformability
… but I will ask authors of a11y spec
dauwhe: historically epub has allowed a lot of different ways to achieve a particular goal, and we've never taken the position that every epub must be accessible to every user
… for example, standard alone audio books are very useful for accessibility, but also useless to a specific segment of people
… this seems like we're taking a step towards saying FXL is an invalid way of presenting content to users
wendyreid: this is all non-normative, but i'm phrasing the note as "the limits of FXL a11y"
… it is possible to do a lot of a11y work for a lot of people, but there are limitations that make it so that some segments will not be served
shiestyle: right now we do not have requirement to make epub accessible, so it will be hard to realize accessible epubs i think
wendyreid: isn't a version of epub a11y 1.1 adopted as JIS standard?
MURATA: it will be later this year, in aug/sep
dauwhe: okay, what wendyreid has proposed sounds good to me
<wendyreid> https://
Wording of Affordance
<dauwhe> https://
wendyreid: i think the only question is, MURATA, is it okay to go with the last suggested text from mgarrish on the issue?
MURATA: different people have different understanding of the word affordance, so let's use something else
wendyreid: I think mgarrish suggested some form of "alternatives"
MURATA: George suggested "available features"
wendyreid: mgarrish suggested that in the specific text we're talking about "alternatives" might work
<wendyreid> An EPUB Publication can have more than one set of sufficient access modes depending on the alternatives provided to enable reading in another mode.
dauwhe: I like that wording
MURATA: there are two instances of the word "affordance". Will we fix both?
wendyreid: the other is in the explanation for accessModeSufficient
<wendyreid> "this property takes into account any affordances for content that is not broadly accessible"
wendyreid: so yes, I think using "alternatives" here makes sense too
MURATA: thank you!
wendyreid: I think that was it
… we're working our way through the issue list
… we have some testing issues, security and privacy, MO
… for security and privacy I've reached out to our 2 reviewers for feedback
dauwhe: looks like we could be in CR soon
… okay, thank you everyone