Meeting minutes
<gpellegrino> preent+
<gpellegrino> https://
referring to document above for this meeting
last week great meeting and have some open questions from last week
will start with questions
Q: What level of WGAG to base on?
Single A level, saying that full achievement of AA level is not possible because some Success Criteria are not satisfiable? Or base on level single A plus all Success Criteria of level AA that are satisfiable by EPUB Fixed Layout?
Hadrien can look into what is currently documented with FXL
interesting to see what is documented, if people document is not meant to be?
Would this be helpful? Do we see any current FXL that claims to be WGAG in the wild?
It seems techniqually impossible to accieve AAA
Having current idea of what is in the wild would be helpful
we can then move forward with what is the current document to see what is possible given current tech
Saying A will cause publishers will neglect to do what they can actually do currently with AA
Kevin says We can make it clear what we can not do with AA, and then highlight what can be done to ensure that everything that is possible
Important to make it very clear what is and what is not important
*not important, actually doable
Hadrien: there is a company that is using FXL that can change the font size, using javascript. It is not really FXL, it switches it to a scroll view to change the font size. It is between FXL and reflowable all done with Java Script. Hard to label these files.
Ask Modesite to do a presentation on their technique, as it is one case that they can change font size
Thanks Hardrien!
*Hadrien typo
Find a way to indicate how difficult it may be for an EPUB Creator without extensive code knowledge to be able to satisfy a Success Criteria? Are there similar approaches in other W3C documents?
Third question.
Example: text sizing is hard to do, but colour is easy to do. It is important to express it, depends on software using and different software
Hadrien: one possible, text well structure (HTML reading order etc) reading system could extract that and create another view or replacement. Think of this as reader mode in some browers. Works if code is not messy. Is also capable in PDF
Would this work? You would be dependent on file being well formed and reading system being capable of doing it
Gregorio agrees. Can be put in, but it has to be very clear how the file needs to be written in a very clear way. Great feature to be explored more in experimental part, but can not be put into the current document that can be achievable right now
Simon: there is technically difficulty and intergrating into external suppliers can be difficult. Image Descriptions is an good example can be difficult to be put into workflow. Tagging is another example. Ensuring machine readable code is something a creator can do by supplier can struggle with this
No solution, but important to know there are different types of difficult or complicated for workflows
We should only identitfy in this document what is capable for FXL, you can achieve most critieria but it can be difficult with some workflows
Maybe difficult to achieve instead of technically difficult?
Gregorio: possible solution is to refer to other specs to assist with the points that are more difficult to support current document
<gpellegrino> https://
This doc has discussion on priority levels and level of efforts and use term can be reasonably achieved for content creators
this could be an approach we use, even if it is still subjective
12 identify in ONIX. Almost none identify as media overlay (though we know there are ones that do this). Table of Contents most identitfied. About half has print pagination, but not in metadata. No current number for clour contrast. Hadrien will look into this more
Gregorio: likes the phrases uses for levels of priority and what can and can not be done
Do you think we should express these levels of effort in success criteria? We know it is hard or unable at this time, but we should express it at this time
<JonasLillqvist> +1
We will move forward with this
Reorganize document by success criteria based on WGAG
Jonas: might be a problem if the document links to different requirements. Can be confusing. A more symantic structure like we have would be easier for the reader. Like we have it right now
Gregorio: We could have it with the restrucutre, or keep it as is and add reference list at end for double checking with links
Hadrien: grouping success criteria can be helpful. What will we put in each group? What is the minimium? How will we group the different levels
Gregorio: on WCGAG there are groups that we can use in this document. We would based it on current grouping for our document
Group by meaning and not success criteria
it is there with notes about how to change font face without naming any font-face. It is good, but it is not a WCGAG requirment, it was removed. Maybe we can reinsert as a note and not a requirement?
Hadrien: Has seen FXL does not embedd font face, gets many bug reports from this. Take a lot for granted that they shoudl not and that leaves us with FXL files that do not work
other that inspecting files, there is not way to indicate this issue, but it does impact the way you read
FXL is designed for 1 font face, if you replace it can break the book. It is a serious problem
Gregorio: it embedded font a bigger issue than other formats?
Hadrien: yes. replacing the font with another can create a lot of bugs and messy font issues
Simon: not rigid rule, but a note that it is important. For example, deliberately choising an ornate font can cause accessibility issues, we can't tell people they can not use the font, but we should advise against this.Wants to know that if it should be noted in Spec?
It is hard to say what is not legible, because what is legible in one group is not for another group
Gregorio: we should do some research on this, advising in a note is fine without going to deep is fine though
Hadrien: Ideally extract text, and display it as reflowable, this can change font easily. Changing font in FXL will be difficult and problemantic
<SimonPRH> ^that was not me! :)
Last Agenda Question: Is the use of multiple spans disruptive to assistive technologies?
assistive tech does not seem to have issue with spans, as long as they dont break the word. A lot of spans is not really problematic for TTS. It is problematic when you try to open the book in browser and try to relarge font
when you do this, the text will overlap text with enlargement.
Span can be problematic with presentation of words, but not with the assitive tech
Hadrien: lots of experience with TTS. It is not a monolithic feauture. You have to break down content into utterances. You have to look at structure (HTML Tags)
If you use browser and tell it what the language it it can break it down. It is not for free. You need a content iterator
It is only with encountering issues and troubleshooting to make it better
You will always encounter edge cases where it can break down content into utterances.
It is hard to say if it is problematic for TTS
Mabye in future we can give recommendations in future, we do open source code, but right now no guideance
Once you break it down into utterances, it passes to TTS. So it is not the TTS itself it is what you do before you pass it to TTS
Gregorio: With multiple spans. Did some tests and it seems TTS works well even when each word is in the separate span. Will test with other assistant technologies
Hardrien: Does not know how other assistive tech works, but thinks it probably works the same as TTS.
Thanks to group!