UDOIT icon indicating copy to clipboard operation
UDOIT copied to clipboard

Feature: add logic for superseding/conflicting text color attributes

Open mrash2 opened this issue 3 years ago • 3 comments

Many of our course pages use text headings with white-on-gray text. For whatever reason (it was done before my time at the institution), this was done by giving the H3 tag a gray background and a span tag within it a white text color.

Example: <h3 style="background: #58595B; text-align: left; padding-left: 5px;"><img style="padding: 5px;" role="presentation" src="https://utk.test.instructure.com/courses/147193/files/11821925/download" alt="" width="40" height="40" align="absmiddle" data-decorative="true" data-api-endpoint="https://utk.test.instructure.com/api/v1/courses/147193/files/11821925" data-api-returntype="File" /><span style="color: #ffffff;"><strong>Basic Elements of the Course</strong></span></h3>

This renders properly as white-on-gray in the browser. However, UDOIT picks up the color attribute of page and/or H3 text and flags this as a contrast error. Is it possible to add logic such that UDOIT recognizes that the color of the span tag supersedes the regular defined color for page text?

image

We can fix this manually by moving the color attribute from the span tag into the H3 (which is how I would have done it to begin with - but again, vast numbers of pages have already been created that way). It would be nice if UDOIT saw that the span color overrides the H3 color.

mrash2 avatar Feb 22 '22 15:02 mrash2

I realize you have a lot of other irons in the fire getting the next release out and doing all your other stuff too. But I would propose that this is actually a bug more than an enhancement request. We're getting a lot of false flags due to this as we test the app in our Canvas Test instance. It seems UDOIT is calculating the contrast ratio using the page text color and isn't taking into account span tags with a font color that indeed should pass the contrast test.

mrash2 avatar Mar 02 '22 15:03 mrash2

Agreed. This is a bug that needs to be addressed in PhpAlly.

cidilabs avatar Mar 02 '22 18:03 cidilabs

Looks like the fix has been merged upstream, so once there's a new release, in theory, all we'll need to do is bump the version in composer.json.

Edit: waiting on a new release here

rob-3 avatar Apr 12 '22 18:04 rob-3

It looks like the latest phpally is 1.2.1 but the package.json is still ~1.1.1? I don't believe this will allow updating to 1.2.x. Is this ready/able to be updated @cidilabs or @bagofarms?

jonespm avatar Dec 06 '22 15:12 jonespm

I believe there are no breaking changes, but it would require testing to be sure.

Thanks, Chuck

On Tue, Dec 6, 2022 at 8:39 AM Code Hugger (Matthew Jones) < @.***> wrote:

It looks like the latest phpally is 1.2.1 but the package.json is still ~1.1.1? I don't believe this will allow updating to 1.2.x. Is this ready/able to be updated @cidilabs https://github.com/cidilabs or @bagofarms https://github.com/bagofarms?

— Reply to this email directly, view it on GitHub https://github.com/ucfopen/UDOIT/issues/785#issuecomment-1339568892, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALBU3TX5N43MIIMCTHEA6LTWL5M4DANCNFSM5PBVMAZA . You are receiving this because you were mentioned.Message ID: @.***>

-- Chuck Crandall

(801) 888-4985 Join us on Slack! https://cidilabs.com/slack-invite/ And check out our webinar series https://cidilabs.com/webinars/

cidilabs avatar Dec 06 '22 19:12 cidilabs