Meeting minutes
<AWK> +AWK
Documentation Check-in "Accessibility supported in WCAG 2"
Makoto: Welcome guest Wilco Fiers
Makoto: Ask Andrew to talk about PDF Adobe and Accessibility Supported
<Makoto> https://
scroll down
Adobe was interested in demonstrating that PDF was accessibility supported...
… also demonstrated how WCAG 2.0 was technology neutral
… Adobe had an interest in showing how to make PDFs accessible, conforming to WCAG 2 SC
… first early versions of PDF had accessibility issues, but was no longer the case by the time of WCAG 2.0 was published
So I lead the work with documenting PDF oriented techniques, some for Flash as well.
… We also have a mapping showing how the PDF standards supports SC
… Obviously not every PDF is accessible, but the same is true for HTML and other technologies.
… Further, our own Adobe tools, Reader and Acrobat Professional, support the creation of accessible PDFs
… This recent activity has highlighted that the maintenance of these PDF support documents stand to be improved...
… early work demonstrated the initial viability of PDFs being accessible.
… PDF has not been the focus of AG WG so there is room for some updating those documents...
Adobe has continued to provide accessibility information and support for our customers.
Makoto: Thank you, PDF important in Japanese market as well.
Wilco: Could you brief me on the accessiblity landscape now, I do not work with PDF much.
AWK: The focus for techniques was how the PDF specification supported SC, and we added some examples from commercial products.
… If I were to look through, I am sure there are some concepts that may have fallen out of favor.
… We are now emphasizing "liquid" over UA Zoom, but there are not techniques for that.
AWK clarifies that language of blocks is supported.
<Zakim> Rachael, you wanted to ask about level of effort vs value perception
AWK: Acrobat might not have a drop down choice for, say Welch, but the PDF spec allows that and language code can be manually added.
Rachael: Chair hat off, we seem to be considering three paths. (1) drop AS, (2) continue as-is, (3) database of AS details.
AWK: I think AS database failed not because of PDF but because it is such a heavy lift. The combinations of browsers and AT...
PDF oriented version is easier because client reader set is smaller. The non-Adobe PDF Readers often do not have good accessibility support, so that is easy to document.
… I think it would be hard just to robust database just for PDF and HTML. I get questions from engineers why just tabbing through a document is not enough.
… Someone has to be dedicated to curating, full time essentially.
Wilco: I was affiliated with first database. ACT has database, and work involves revisiting every rule once per year...
… We don't to be a bug repository, but absolutely there are not about accessibility support with most popular current products...
,..but the task force is not comfortable listing product names and version.
Wilco: There is an ARIA support group which might be interested in doing some of this work, but ARIA is more standardized than the rest of the HTML / CSS world.
Learn from Wilco's experiences
Wilco: The browser developers are always changing their products and technology constantly evolving.
Makoto: Use case 6 is Accessibility Supported database, which we have talked about before and touched on just now.
<Makoto> W3C's Accessibility Support Database https://
<Makoto> H37_4: Screen readers read the alt on img elements https://
Makoto: Join me in welcoming Wilco for talking about some of this work.
Discuss H37_4 screen reader and alt text.
Makoto: How did you start this work?
Wilco: Should be right from the technique.
AWK: Reads from H37 and draws parallel.
Makoto: In Japan, we did a similar thing. We created test files and report results, testing with PC Talker popular Japanese screen reader.
… but still we had trouble determining what behavior was pass / fail. We struggled to document test procedures and expected results.
Wilco: Most of these comes from the Techniques themselves.
Wilco: An interesting example is the Accessible Name calculation. We have about 100 test cases.
<Wilco> https://
<Makoto> Accessibility Support (a community driven effort) https://
<Makoto> ACT Rules https://
<Makoto> an example of documented ACT rule https://
Makoto: Last week at AG WG meeting I mentioned some community driven activities.
Makoto: Could Wilco walk through iframe analysis?
Wilco: ACT Rules is an ad hoc approach. We write down what we know, and we test a lot.
… outside volunteers can add and report on behaviors. ACT tries to look for edge case and problems.
… iframes is good example of how bad and variable things are. Focus, support for title, varies so much from browser to browser
… there is not canonical behavior under ARIA for iframe and the HTML spec leaves it open. It is up to browser developers.
AWK: This underscores the challenge with a database approach. Authors have to do homework...
… some authors do the best they can, some avoid iframe because it is variable, and some authors have no choice but to implement iframes.
<Makoto> In IRC, Racheal wrote three possible path (1) drop AS, (2) continue as-is, (3) database of AS details.
Wilco: This is a good example of a technology that has been around awhile, has gotten lots of attention and discussion, and we still do not have clear solutions.
Makoto: Coming back to Rachael question, three choices, and the third option to develop a database seems like it has significant challenge.
… What is main challenge?
Wilco: I think it is financial. It needs robust staffing.
Makoto: Suppose money is not a problem.
Wilco: Then it becomes a policy decision. Does W3C only support the most accessible browser? Only open source projects?
… With unlimited resources, it would still be a problem to dictate which products does things right and which do not?
Rachael: Is there a path for opening contributes? Make it informational. Open paths for contributors.
Wilco: That has been the approach from the beginning. The people who can contribute have vested interests.
AWK: UA developers are not going to be entirely forthright because they are trying to keep customers happy. There is not much appeal to public bug reporting.
Wilco: This is why the ARIA working is getting some tracking, but funding remains a big issue.
… The work is also resistant to automation, can't emulate human use of screen reading software.
Makoto: JIS has been struggling with this issue. We have created some test files and tested with variety of AT and browsers...
… so I can appreciate the scope and breadth of this work.
Makoto: Could a collect of sample test cases be a good start?
… Then our work could focus on testing with UA, and not creating the test files.
Wilco: There are a couple initiative creating test cases, so one wants not to duplicate work.
… sets of accepted case test files could be feasible.
Makoto: We are out of time for pro/cons discussion. Please all revisit that section of document.
… I have merged comments together. Please check, and add content and comments as you like.
Poornima: I want to speak to keeping accessibility supported.
… It is a great deal of work but it is so valueable
… examples for accessible supported for each guideline is going to be important.
… We have example with 3 for Headings and it is important to keep that model going forward.
… It helps with implementation.
Rachael: Our next step is put work into a pull request. Timing for that is important.
Makoto: We developed use case and based from that have pros and cons and we can finalize that next week.
… We should present something at TPAC.
<Makoto> Makoto: I'm gonna draft this subgroup's pull request later this week. Once I'm done, I'm gonna share it with you all so that you can do the preview for next week's meeting.