website
website copied to clipboard
hackforla
Research impact of techniques in the WCAG 1.4.4. Guideline for resizing text
Overview
Research the feasibility and impact of implementing alternative Accessibility techniques, so that Hack for LA's website can score the highest Accessibility rating possible, while still being easy to use for all visitors.
Details
Zoom functionality in modern browsers ensures that the WCAG 1.4.4 guideline on resizing text is satisfied, but there are alternative techniques for compliance that offer accessibility advantages. In this issue we will research the feasibility and impact of implementing alternative techniques described in the guideline, in particular: (1) providing accessibility controls on the page, and (2) Specifying relative font sizes and resizing text containers and layout regions to scale with text size
Action Items
- [ ] Research the impact of implementing:
- [ ] Research the alternative of ensuring that text containers resize when the text resizes AND using measurements that are relative to other measurements in the content by using one or more of the following techniques:
- C28: Specifying the size of text containers using em units
- Techniques for relative measurements
- Techniques for text container resizing
- [ ] Document findings in a Decision Record.
Resources/Instructions
- W3C Web Content Accessibility Guidelines (WCAG) 2.0
- Understanding Success Criteria 1.4.4: Resize Text
- Sufficient techniques for WCAG 1.4.4
- How to change text size in Google Chrome
Hi @roslynwythe.
Please don't forget to add the proper labels to this issue. Currently, the labels for the following are missing: Complexity, Role, Feature
NOTE: Please ignore the adding proper labels comment if you do not have 'write' access to this directory.
To add a label, take a look at Github's documentation here.
Also, don't forget to remove the "missing labels" afterwards. To remove a label, the process is similar to adding a label, but you select a currently added label to remove it.
After the proper labels are added, the merge team will review the issue and add a "Ready for Prioritization" label once it is ready for prioritization.
Additional Resources:
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@ExperimentsInHonesty To determine the complexity, I would appreciate your input on the scope of this issue. Should this issue focus just on the evaluation of compliance or should it include analysis/decision re: alternative CSS approaches? And should we broaden the focus to include not just fixed font size but also other CSS issues that could impact text scaling, such as fixed width containers or the use of text within images?
@roslynwythe good questions. i think I will need a better understanding of the type of rabbit hole we are looking at. The last accessibility audit we did really was focused on alt and not using h1-5 tags correctly (using some standard testing tools specified in this article Which accessibility testing tool should you use?. So I would love to know what if any testing tools we would be using for this round and just generally more about these new requirements.
@ExperimentsInHonesty Thank you for the link to the article Which accessibility testing tool should you use? I ran a few pages against two accessibility checkers and our pages did not fail SC 1.4.4.
Use of absolute units is not a recommended practice, because it overrides the user's style sheet. You can see this by going to your chrome Appearance settings and changing the font size to Large. On our site there will be no change. However, unless a site specifically restricts it, all modern browsers have a built-in zoom function, and that is considered an alternate means of scaling text, thus allowing SC 1.4.4 to be fulfilled.
Other accessibility issues were identified and issues will be ready shortly
@roslynwythe Thanks for the update. Sounds like this issue is ready for a decision record.
@roslynwythe When making the new issues, just confirm that we don't duplicate the items that are still open from that audit. Those items can be found by looking at issues with the label feature: accessibility
@ExperimentsInHonesty This issue has been completely rewritten. It now explores the impact of implementing several techniques which would make it easier for users to resize the text on the website.
@roslynwythe at the top of this issue in the overview section the text says:
layour regions
I think you meant layout regions.
Other than that, this looks good. If you are ready for me to prioritize it, add the ready for prioritization label.
Hi @kevin31yu, thank you for taking up this issue! Hfla appreciates you :)
Do let fellow developers know about your:- i. Availability: (When are you available to work on the issue/answer questions other programmers might have about your issue?) ii. ETA: (When do you expect this issue to be completed?)
You're awesome!
P.S. - You may not take up another issue until this issue gets merged (or closed). Thanks again :)
Progress: Completed reading and checked off the tasks Blockers: I am not sure what to next Availability: 8 hrs ETA: Not sure
Hi @Anahisv23, thank you for taking up this issue! Hfla appreciates you :)
Do let fellow developers know about your:- i. Availability: (When are you available to work on the issue/answer questions other programmers might have about your issue?) ii. ETA: (When do you expect this issue to be completed?)
You're awesome!
P.S. - You may not take up another issue until this issue gets merged (or closed). Thanks again :)
Hi, below I have attached a google doc with a decision record including my findings of the impact of implementing G178 and alternative techniques C28, C12, C13, C14, SCR34, and G146 to comply with the WCAG 1.4.4 guideline on resizing text. I appreciate any feedback!
https://docs.google.com/document/d/1CneoiEo4GDFXXWJnaZH56XyYUBGSKnlG2ZiP8L24eiE/edit?usp=sharing
Thank you @Anahisv23. You have done a lot of great research and prepared a well written summary. It seems that we have three decisions to make:
- Do we adopt relative units for font sizes, to accomodate user resized text?
- If we adopt 1 above, how do we scale containers to accomodate the resized text?
- Do we provide controls on our web pages to provide a GUI for users to resize text, rather than having to use another method (ie, browser or system settings or a user style sheet)?
Let's focus on 1 and 2 above. For information about Decision Records, please see https://github.com/hackforla/website/wiki/Decision-Records-on-Solutions-Not-Implemented https://github.com/hackforla/website/wiki/Decision-Records-on-Solutions-Adopted
I do have some questions:
Regarding decision 1:
- Do you recommend the use of percent font size over the use of em for font size? If so, please explain why.
Regarding decision 2:
- I was a bit surprised to read that the method of calculating container sizes is considered easier than relative em units. Did I understant that correctly? Do you know which method is more commonly in use and why?
- Is the "liquid" layout a separate technique or is it also the use of relative units for text and containers?
- What are the pros and cons of specifying container size as percent vs ems?
@ExperimentsInHonesty I think I tried to put too much into this issue. I believe that before we consider providing accessibility controls on the page, we first need to determine feasibility and techniques for allowing text and containers to resize. So I suggest removing the first Action Item. Also I suggest removing the last item, the Decision Record, because that decision should probably be made and documented by a dev lead.
Also I'm not sure if I should hide the comments with Anahis's work and my partial review
@Anahisv23 Good job with the analysis. Please move this document into the team Google Drive.
@roslynwythe if I just read the analysis document. I think we need to talk about this in the merge team meeting and I will add it to the agenda.
- Add the dependency of the issue that re runs the accessability audit #1347
- add text about rewriting the issue if its still needed after the audit. See comment above.
Hi @ExperimentsInHonesty, thanks! I want to add the document into the team google drive but I don't currently have access so I requested access. As soon as I get access I will move the document there.
@Anahisv23 you have contributor rights on the "HackforLA.org website" share, In that share, please place the file in the folder "HackforLA.org website folder/Files related to dev issues/issue 4227 Thanks!
Hey @roslynwythe is there a link I can access to join the google drive bcs the link I'm currently using states I do not have access? I'll include the link below.
https://drive.google.com/drive/u/0/folders/1p76K0FgfiAWeIIEyoyJ_Iik8FVj8cBjT
@Anahisv23 I added you to the drive using the email address from the hackforla website roster.
Thanks @ExperimentsInHonesty and @roslynwythe. I have added the document to the google drive.
@Anahisv23 Thanks for the update. @roslynwythe please review Google Doc: Decision Record - Hack for LA Issue #4227
@Anahisv23 I went and looked at this link: Decision Record - Hack for LA Issue #4227 and its a google doc, but its not in the website project drive. You have made it so that anyone can edit the file, but that is not the same as moving it to our google drive. Additionally, there is a pdf in that folder, but we need the editable Google doc
- Please place the file in the folder HackforLA.org website folder/3 - Developers/Files related to dev issues/issue 4227
Hi @Anahisv23, thank you for taking up this issue! Hfla appreciates you :)
Do let fellow developers know about your:- i. Availability: (When are you available to work on the issue/answer questions other programmers might have about your issue?) ii. ETA: (When do you expect this issue to be completed?)
You're awesome!
P.S. - You may not take up another issue until this issue gets merged (or closed). Thanks again :)