openacr
openacr copied to clipboard
GSA
Simplify the UI for most editors
Most editors aren't going to need to fill in all of the fields for all of Section 508. We should be finding ways to depreciate those examples which aren't needed.
On the About page we could ask folks to check boxes for all of the elements that comply. This would include the tables/chapters as well as the sections within Tables 1 & 2 (Web, Electronic Docs, Software, Authoring Tool).
We should also have some guidance somewhere about when these are needed. After reading the document from NASA, I wasn't clear that the FPC was needed.
See the help from https://sewp.nasa.gov/documents/Section_508_Guide_111821.pdf "If your product cannot be evaluated using the current criteria, Complete Chapter 3: Functional Performance Criteria."
I can't see that from the text from VPAT instructions. https://github.com/CivicActions/accessibility-data-reference/blob/main/VPAT2.4/VPAT2.4Rev508--February2020-instructions.md
The FPC only apply in 2 specific situations - when seeking equivalent facilitation and if there is not a standard that applies to a particular technology. However, in practice many agencies want the FPC filled out to help understand functional use, mitigation, and risk to the agency.
Also, another point of disagreement between agencies is how the software standards apply to web based software when WCAG standards are not met. Technically if WCAG is not met for web software then Chapter 5 applies - but in practice there is little applicability in many of the standards beyond what WCAG already covers and web content doesn't have access to platform features like software does and can't meet those additional requirements. So in practice the advice is to not apply Chapter 5 to web based software - but not all agree.
Finally 503.4 was meant to apply to web as well for placement of caption and description controls when synchronized media is present for web or software - but was excluded when WCAG is met for web by some loose language in the standard.
This is great context @mraccess77
It occurred to me that much of the FPC could be auto-populated from WCAG. We have a mapping defined, so could just auto-populate some of the material and then leave it to be edited.
From a perspective of webform simplicity though, we just want t make sure that the FPC is optional, unless none of the other tables are filled in. Just trying to figure out how to ensure that we are validating this properly.
I guess in cases of disagreement we either need to leave it optional or get the position of the US Access Board and default to that.
With 503.4, what do you suggest?
We could possibly add a link from https://gsa.github.io/openacr-editor/chapter/success_criteria_level_aa
To this section of the form: https://gsa.github.io/openacr-editor/chapter/software#503.4.1
To remind folks this is required for web as well as software?
@mgifford The mapping link did not work - as an FYI there is also a mapping from functional performance to criteria in EN 301 549 as well.
I'd recommend making the FPC always available but allowing them to be optional and have a note there explaining the current situation.
As for 503.4 including them would be good - they are called out here by TT in the test process: https://section508coordinators.github.io/TrustedTester/media.html
This is the link for the mapping @mraccess77 hopefully that works better for you: https://github.com/CivicActions/accessibility-data-reference/blob/main/mapping-wcag-to-fpc-en.yaml
I couldn't find the much beyond the EN 301 549 Functional Performance Statements in https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.01.01_60/en_301549v030101p.pdf
If you can send me something better, I would appreciate it.
Your suggestion of having a note. Maybe something like: "FPCs is a backup to describe barriers that do not fit with any of the other categories. It can optionally be used to summarize the limitations and possibly the work-arounds which people with various disabilities might face."
That will need more word-smithing, but..
I can't see modifying WCAG, but could add a note in 1.2.2: Captions, 1.2.3: Audio Description or Media Alternative (Prerecorded), 1.2.4: Captions (Live), & 1.2.5: Audio Description (Prerecorded) to link to https://gsa.github.io/openacr-editor/chapter/software#503.4.1
And could provide help text with links to the TT test process in the notes there.
USAB did a mapping of WCAG 2.0 Level AA which can be found here: www.access-board.gov/ict/wcagtofpc.html
Our mapping does not address AAA SC, nor the SC new with 2.1.
There are some minor points of disagreement between our analysis and the table in EN 301 549. Some of that comes from EN having different FPC for limited manipulation. Also, EN has something like directly applicable and partially applicable. We did not find that distinction clarifying, and did not use it.
One take-away we had is that mapping WCAG 2.0 SC to FPC as a way to document meeting FPC is not great. It is very uneven, and there are gaps. It does not work at all for hardware. Better than nothing, of course.
- Yes, some agencies are asking for FPC assertations in ACRs, even though our reg does not require that (and even gently discourages it). I am pretty sure the ITI VPAT facilitates inclusion of FPC.
- It would be of utility for OpenACR to have the option to include FPC. Leaving it out by default is the better than including the FPC by default IMHO.
My own preference would be for 503.4 to be included for web content, but that it not be conflated with SC 1.2.x. It is a small gap, and it's always possible that the gap will be addressed by the AG WG.
@mgifford -- I am getting a 404 from your .yaml link above.
Pinging @kengdoj to invite comment.
@bruce-usab can you access https://github.com/CivicActions/accessibility-data-reference
Would be totally useful to update your FPC map for other SC as you've stated. Also 2.2 which should be coming out soon.
We took the table that you produced in the wcagtofpc.html and just made that a CSV file, then a YAML file. I just updated that in the YAML file comments to make this more clear.
I looked again in the PDF for EN 301 549 and can't see the table you're referring to. I couldn't find much that was tied to directly applicable or partially applicable in the latest version of the document. I did find references in an earlier version, but not the one from 2019. Maybe I'm missing something here.
Ultimately having consistency around this would be useful. If we document the intentions clearly, in plain language, in the editor, that should be a good step.
Mapping is in appendix (Annex) B https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf Also as an FYI the latest version of EN 301 549 is v3.2.1
@bruce-usab can you access https://github.com/CivicActions/accessibility-data-reference
Nope. I see @mraccess77 had the same difficulty.
Would be totally useful to update your FPC map for other SC as you've stated.
Understood. USAB had been hoping to defer that analysis to W3C AG WG, but the clock is ticking!
We took the table that you produced in the wcagtofpc.html and just made that a CSV file, then a YAML file. I just updated that in the YAML file comments to make this more clear.
Perfect. That was not clear to me until now.
Thanks @mraccess77 for the link! Print (and PDF) page 105.
Table B.2 uses P (Primary relationship. The requirement supports the functional performance statement.) and S (Secondary relationship. The requirement provides partial support.). As I noted above, USAB didn't find such a distinction to be sufficiently unambiguous.
- EN 301 549 has
- Usage with limited manipulation or strength,
- Usage with limited reach
- 508 has:
Right you are @dmundra - let me see what I can do to address that. This is all public data as far as I'm aware. Sorry I shared a private link, it's not very evident in the GitHub UI.
2X thanks @mraccess77 for both the pointer to Annex B & v3.2.1. I had missed the Annex and didn't realize that the new version was out.
This would be s much more useful a table if it were put out in a proper machine-readable format....
What I do hope to share here soon is both a CSV & YAML (and some JSON versions) listing the input from that HTML table. Better to just have cleanly structured data if we can. Ideally this would be in a common open repository, but sadly nobody Is doing this in a centralized place.
Yes, some examples of what a primary or secondary relationship here is would be useful. Although there is some vagueness about "supports" & "partially supports" in all of the ACRs that I am aware of. I'm not sure there is a clear definition. We have taken the best language we could find and put it into the Result Choices section of https://gsa.github.io/openacr-editor
We can try to add more here if there is a stronger way to clarify this.
Our current contract is focused on Section 508. We are trying to design this to support EN 301 549 & WCAG as they evolve. We are also thinking about the implications of making this multi-lingual to support better international buy-in. That said we've focused on English for this MVP. The international version of OpenACR will likely follow the same approach as the International Edition of Version 2.4 and simply have both a FPC & FPS criteria, even though they are almost the same.
We might be able to auto-fill those components that are identical, so that there is no duplication in the content. If it is just as simple as those two sections of the table being slightly different.
Any discussions of going with one approach vs another?