-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Address support tables 2.0 feedback #521
Conversation
SummaryPending explanations/implementations/corrections on items I was unable to verify this is good to approve :) General Code ReviewGenerally, everything looks awesome @alflennik ! I only had the following question, but it doesn't bar this PR from being approved.
In reference to the original PR
❌❔ the preview currently reads
❔ unable to verify, could not find an example of a single one in the preview
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me @alflennik! While I do have additional questions listed below, those to me aren't blocking as they can be updated once we receive further feedback and directives there.
What I do think is blocking (which this PR wasn't intended to touch or address) is around how the CANDIDATE
/RECOMMENDED
status is evaluated. server/apps/embed.js lines 92:94 is being done against all reports which have existed and would have previously had a CANDIDATE
/RECOMMENDED
status. This can quite easily prevent the correct disclaimer being shown above the table. This evaluation should be done further down against latestReports
so it is actually done against the data being shown in the table.
<ol> | ||
<li>applicability and validity of the tests, and</li> | ||
<li>accuracy of test results.</li> | ||
</ol> | ||
</div> | ||
</details> | ||
{{else}} | ||
<div id="embed-report-status-container"> | ||
<div id="candidate-title" class="recommended"><h3>Recommended Report</h3></div> | ||
<details id="embed-report-status-container"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for updating the markup to allow the RECOMMENDED
disclaimer to be a part of the updated disclosure as well!
<div id="embed-report-status-container"> | ||
<div id="candidate-title" class="recommended"><h3>Recommended Report</h3></div> | ||
<details id="embed-report-status-container"> | ||
<summary id="candidate-title" class="recommended"><span>Recommended Report</span></summary> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be curious about what the community's thoughts would on this title. Should the disclaimer also be the reverse of the CANDIDATE
disclaimer, so Approved Report
?
This is also done on the application's Reports pages as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to have them review it. Can we promote one of the reports to a recommended state on the sandbox?
@aleenaloves First of all thanks for the detailed review! |
@aleenaloves About "Increase the color contrast of the table borders," you noted that the contrast value is short of the recommended 3:1 value. It seems like this is an issue for the entire site, since we're reusing the same value from the entire site. How do you think we should fix it? |
@aleenaloves Thank you for noticing that the test titles have inconsistent names (some have the word Example and some don't). While we could definitely work around that within the embed system I think it makes sense to take this as an opportunity to improve the overall consistency of our data, and I'll bring this up with the rest of the team. |
@howard-e Thanks for finding that issue with the candidate / recommended algorithm! |
You're right that this is an issue for the entire website. Since this would then be a design concern, it may make sense to get isaac's input on it - but irregardless, irrelevant to this PR in particular. Since the 2nd part of matt's original step 11 also included:
Not sure what tables he's exactly referring to, but if it's the But i defer to you on what you think he meant/what you think would be best in this scenario. |
I did make an issue about the contrast here, w3c/wcag#3102, but for now it seems like the best move is to keep the contrast consistent with the other tables on the site which was the ask originally. |
thanks @alflennik ! loved the investigation ~ i'm good to approve this, pending @howard-e's notes :D |
@howard-e @aleenaloves So I reproduced and fixed the issue Howard found, but I discovered another issue in the process - namely that the caching solution in use right now has no invalidation built in, so it could potentially get pretty far out of date and would potentially only be refreshed when deploys happen. I'm currently working on a solution to that. |
I talked to a couple of folks at WCAG and buttons and tables are not subject to the 3:1 requirement - seems like a good bit of knowledge for the toolbox for next time 😄 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Great job!
Implements fixes for additional issues found here: w3c/aria-practices#2569