Content reporting

[mattgarrish]

in terms of tailoring the wcag assessment criteria, reporting the following in the data section will really help:

• videos - file, id if present, controls enabled, tracks
• audio - same as video
• forms - file and id
• scripts - file

The next level down would be to know about the presence of:

• iframe
• embed
• object
• canvas
• map

I expect those will be in small enough numbers that it won't bloat the report, and are useful to point out for a few SCs.

A report of whether mathml is present would be useful for metadata generation, but I don't want a listing of every equation. Same for whether pagebreaks/pagelist were found.

The other manual difficulty will be in determining compliance to 1.3.1 (info and relationships), but I don't think we need anything for this. It requires someone to go over the markup.

That's everything I've been able to think of for now.

[mattgarrish]

It would also help to know if the publication is using any epub fallbacks, as they are not accessibility supported and need to be reviewed.

• fallback attribute on manifest items
• bindings element in the package doc
• epub:switch in the content
• epub:trigger in the content

[rdeltour]

@mattgarrish the following is not implemented yet:

• fallbacks, bindings, epub:switch, epub:trigger: these are not accessibility supported, but not necessarily harmful, so should not necessarily trigger a violation. How should they be reported?
• forms (file and id): what do you mean? what do you exactly need the report to contain and why?

We can create separate issues for these, once we clarify the requirements.

[mattgarrish]

Not necessarily harmful, but more often than not harmful. What I'm doing is reporting their presence with a warning that they need to be checked to ensure that they aren't being used in a way that accessibility depends on them: using accessible alternatives as fallbacks for spine and switch, disabling default controls after trigger support is established, etc.

A number of WCAG SCs focus on support for interaction with form elements (operability, error handling, etc.). I don't need to know where form elements occur so much as whether they occur to allow those SC to be filtered out when they don't apply. I really just need a boolean that says whether any elements were encountered (form, input, button select, datalist, textarea, output, progress, meter). It's going to be imperfect, as it won't account for custom aria controls, but I suspect those are extremely rare.

[rdeltour]

Not necessarily harmful, but more often than not harmful. What I'm doing is reporting their presence with a warning that they need to be checked to ensure that they aren't being used in a way that accessibility depends on them: using accessible alternatives as fallbacks for spine and switch, disabling default controls after trigger support is established, etc.

OK. So Ace wouldn't report them as violations, but it would still extract them in the data section (as we do for images, etc). Correct?

I really just need a boolean that says whether any elements were encountered (form, input, button select, datalist, textarea, output, progress, meter)

OK, noted!

[mattgarrish]

but it would still extract them in the data section (as we do for images, etc). Correct?

Right, I just need something in the data. They need to be looked into, but as you say, you can't assume that they're violations.

[rdeltour]

Tracked as #75 and #76.