About: Add page to about section that explains the AT support tables

[mcking65]

Resolve #2970, #3019.

Preview Page

Preview Assistive Technology Support Tables | APG | WAI | W3C

---

WAI Preview Link (Last built on Wed, 22 May 2024 22:23:55 GMT).

[mcking65]

@boazsender

Love the clarity, brevity, and structure of your first draft!! Dividing the content into explanations and recommendations is spot-on. I really like your choice of presenting the usage aspects of the content as 'recommendations'.

Thoughts about next rev ...

I think it would be especially helpful to provide a bit more color around the meaning of 'must' and 'should'. We might want to choose two simple example assertions, one 'must' and one 'should' and contrast them, explaining why the must is a must and the should is a should.

In the recommendations, one thing I think we should say more explicitly is that if you are testing your own implementation of a pattern using an AT that scores less than 100% for must and 100% for should, you should determine whether the AT failures are impacting your assessment of your implementation before making changes to your code. If possible, you should test with an AT that scores 100% if one is available. these recommendations probably fit under "Don’t Code to the Bugs".

Not coding to the bugs is the most actionable recommendation. It should probably be first.

I am thinking about how to change "Understand the failures" into something more actionable. What does one do with that understanding? Do we really want people to completely avoid implementations of a pattern that fall below 100% must? Perhaps by understanding a failure, they can determine what specific attribute of an implementation is problematic and design around it while remaining within the pattern's guidelines.

[boazsender]

@mcking65 Thanks, I'm glad you like the first rev.

one question:

if you are testing your own implementation of a pattern using an AT that scores less than 100% for must and 100% for should, you should determine whether the AT failures are impacting your assessment of your implementation before making changes to your code

Can you say more about why you think this?

[boazsender]

@mcking65 just reviewed the updates. I think this is ready to go!

[a11ydoer]

@mcking65 Can we change "all ways of implementing that pattern" with "multiple ways of implementing that pattern" which was used in the suggestion below?

"If there are multiple implementation examples of..."

[mcking65]

that would change the meaning. I revised the wording a bit to hopefully resolve the lack of clarity ...

If the must-have support level is less than 100% for one example implementation of a pattern, that does not mean every other way of implementing that pattern will present assistive technology users with the same problems.

[a11ydoer]

@mcking65 Would it be clearer if we update "that provide 100% support" as "that provide 100% must-have support"?

[mcking65]

It does not matter if it is a must or should that is being accomodated. However, your question prompted me to clarify by avoiding the need to use support levels as the factor that needs to be considered when making this judgment.

[a11ydoer]

@mcking65 did you intend to remove "being accommodated" from the the sentence?

[mcking65]

I reworded so it is simpler with a new commit I will push soon.

[a11ydoer]

@mcking65 I reviewed and added three comments for your consideration. The contents look great, and thanks again for creating this useful content for APG users, @mcking65 and @boazsender!

[mcking65]

@howard-e Check examples/index.html / coverage (pull_request) is failing.

I looked at the logs and couldn't figure out why. It seems like a diff command is erroring out.

I am going to go ahead and merge. I am guessing the worst case here is that the coverage and quality report is not getting updated. I hope this is something you can easily resolve before we publish. If not, perhaps we publish again with any necessary fix/update.

[howard-e]

@howard-e Check examples/index.html / coverage (pull_request) is failing.

I looked at the logs and couldn't figure out why. It seems like a diff command is erroring out.

Seems this happened because changes went into main from #2775 which affect the coverage report without the script being re-ran (which is also curious) but my guess is the script was just accidentally skipped during a later push on that PR.

I am going to go ahead and merge. I am guessing the worst case here is that the coverage and quality report is not getting updated. I hope this is something you can easily resolve before we publish. If not, perhaps we publish again with any necessary fix/update.

@mcking65 it was easy enough to resolve, in re-running npm run coverage-report. But that made me notice that EVERY example was reported as using event.keyCode, the amount reported as using event.which, 60 which seemed very wrong. That's because the skipto.js utility wasn't being ignored during the generation and adding to the metrics. So I've filed #3026 to ignore skipto.js and to also re-run the script so report can be up to date, and accurate.