Community

Not if the link color was set by a style tage like this: style="color: #df2d27; ". If that is the case, then yes, each would need to be updated seperately. If the institution uses designplus, you can use a custom css on each page. It will take a second or two to show once the page is rendered but then you can modify the base color of all links on the page by redefining the CSS for links. I know you know this but it may be useful for others. ... View more

Sadly, this is not a surprise. We have known this for quite a long time. Note the thread above. Instead of the instructor changing the links individually, perhaps the institution's Canvas administrators chould change the Canvas theme to a red or another color that is WCAG 2.x compliant? Doing so would update all the links in the instructor's course as well as any other course using the default color. ... View more

I agree with Tom, Jess and the others who suggest compliance proactively, making WCAG compliance the default, not the exception. That said, I note the color of links in this forum, are not compliant. The red of the Canvas logo, when placed on a white background, fails 3 of the 4 WCAG standards.  Foreground:#D54F37 Background:#FFFFFF The contrast ratio is: 4.2:1 Text failed at Level AA Text failed at Level AAA Large text passed at Level AA Large text failed at Level AAA (Results from Colour Contrast Analyser) ... View more

I can totally see how the same image could be uploaded multiple times because of the inconsistency in options between uploading and embedding an image.. You make a good point.  ... View more

Christopher, it is an interesting thought, but generally I disagree. I don't think they need a DB to track tags. A consistency problem should not lead to over engineering. Instead, I think Canvas should update the RCE to correctly and consistently implement image handling. The embed image function needs to act like the upload function. It needs to not auto-fill anything for the alt text and it needs to have a button for enabling and disabling decorative tag. Ideally it would also require the person to enter an alt tag or click decorative to complete the submission or edit--again to act like the image upload function. It is the individual's responsibility to enter the appropriate alt tag for an image. Even if it is the same image used over and over. I don't think it is too much to ask Canvas to make their UI consistent and compliant.  ... View more

Thank you very much. ... View more

 @Chris_Hofer , thanks for the reply. In looking at your post I don't think erinhallmark‌'s response to you is adequate in light of the additional details. It is one thing to say, "please make that suggestion" when the issue is just inconsistent functionality. While inconsistency is true in this case, it goes further. The inconsistency potentially causes Canvas to produce non-accessibility standard code. In the WebAIM guidelines for WCAG 2.0 implementation, the second point on the first guideline (1.1)  states: Images that do not convey content, are decorative, or contain content that is already conveyed in text are given null alt text (alt="") or implemented as CSS backgrounds.  Note this guideline is not even to meet AA or AAA standards. This guideline set is to meet the most basic WCAG 2.0 Level A, which alone, would not meet the current 508 refresh standards. Thus this inconsistency is a bug that potentially causes decorative images to also have non-null alt-text tags. To put it bluntly, this is a bug that causes Canvas to potentially produce non-WCAG 2.0 compliant code. I don't think that this should necessarily cause the delay of this feature release, but it should be treated as a bug and not a community-based "would-be-nice" suggestion. I hope Canvas treats it this way. If this is the wrong place to notify Canvas of this bug, please accept my apologies and point me to the right place. Thanks, John ... View more

New Alt-Text/Decorative Image Features Potentially Results in Canvas Violating WebAIM Accessibility Standards This update has many great features in it. Thanks to you all at Canvas for continually striving to improve Canvas and addressing problems. I like the new grade book and look forward to seeing the best way to implement the grading policies. My post today, however, is about the inclusion of the alt-text field and decorative checkbox. These are wonderful, build on similar functionality in the accessibility checker, and illustrate the small things that can be done to help content creators do the right thing and make their content accessible. My concern, however, is that these added features makes Canvas seriously inconsistent within the Rich Content Editor (RCE) and the image insert functionality on the images tab. In fact, this inconsistency causes Canvas to be potentially non-compliant with WebAIM standards.   If an image is uploaded via this new feature, the person uploading the image can mark it as decorative or enter an alt-text. By default the alt-text field is left blank. If the person uploading the images leaves it blank, the image upload button remains unavailable. The person must enter an alt-text or click decorative. While this tactic could result in the person just putting in gibberish in the alt-text field to get the image to upload or clicking decorative even when it is not, it at least makes the person have to think about these options. [I'll leave the debate about the wisdom of this approach to others as it is philosophical, not technical.]    Nevertheless, the problem is that the RCE editor and Canvas image embed feature handles adding images already existing in the files area very differently. It also handles editing the newly uploaded file badly once the page is submitted and the newly uploaded images is added to the course. If the image is added via the Embed Image icon in the RCE and the image is selected via the Canvas tab, Canvas fills in the file name as the default alt-text. Already we see inconsistent behavior.  If there is wisdom in making the person selecting the image enter an alt-text or clicking decorative when uploading an image, shouldn’t it also do so when the image is already existing in the course file area? Additionally, by having the filename auto-fill the alt-text box, the person selecting the image can just submit the selection (or it is automatically filled in if the images is selected on the images tab) and the useless alt-text (i.e. the filename) will be placed within the HTML. Having the file name in the alt= HTML code will allow the image to pass the RCE accessibility checker even when we all know that having the file name as the alt-text is not helpful and in this case is even harmful as it gives a false impression of no accessibility issues in the accessibility check. The person selecting the image can also delete the file name and insert the image with no alt-text. Again, inconsistent behavior. At no time can a person using the Image Embed tool to make an image decorative. Another inconsistency, and this one has significant consequences.   In terms of what to put in the alt-text field, I’d argue there should be consistency. If the Image Embed function cannot be disabled until an alt-text is entered, then I think a blank is better than auto-filling in the file name. It at least would cause the image lacking an alt-text to fail the accessibility checker. Right now selecting an existing image in files gives the worst of both options. It puts the filename giving the impression the image is accessible when in reality the alt-text is useless to the seeing-impaired user. The most consistent behavior would be leaving the alt-text field blank when the person selects the image in the Image Embed icon in the RCE and they cannot click update until an alt-text is entered. Same if the image is being edited. A blank alt-text equals no submit/update button functionality.   There is an additional problem with the current functionality. The decorative checkbox is nice, but it is only available via the upload or remediating an image in the accessibility checker. If the person uploading the image selects decorative, then this option cannot be unset without manually editing the HTML. Similarly, if an image is uploaded and the decorative box is not checked, it cannot be made decorative later. The only places that the decorative options are available are in the upload option and the accessibility checker. One might assume that you can select an image, click the Embed Image button, delete the alt-text and then update the image so that it has no alt-text and thus the accessibility checker will catch it. Sadly this is an incorrect assumption. The Embed Image function will not allow the person to save an image without an alt-text if it had one previously. It just ignores the delete and retains the previous alt-text.   Similarly, if the image was marked decorative, there is no way to undo it. Clicking an image and clicking the Embed Image icon shows the blank alt-text, but it has no decorative checkbox functionality so this cannot be toggled on and off. Moreover, it does not recognize that this is a decorative image. As a result the alt-text field allows an alt-text to be entered. Thus it allows the editing of a decorative image and the adding of an alt-text to it. As a result, the RCE creates code that is both marked data-decorative="true" and having text in the alt= tag. This is a WAI standards violation as images marked decorative should have an alt-text that equals null. (See both the WebAIM website regarding alt-text and decorative images, and w3.org’s page on alt-text and decorative images.) This ultimately makes Canvas non-compliant. This is because the RCE is a primary function throughout the application. The only way to fix an image incorrectly coded as decorative or to remove the alt-text to be blank is to directly edit the HTML, removing the alt-text or data-decorative="true" code manually. If alt= is made to equal “” and the decorative tag is removed, then the accessibility check will flag the image and it can be updated to be decorative or have an alt-text. Having text within the alt tag while the image is marked as decorative does not result in an error.   Again, this update is great and I applaud Canvas’s ongoing efforts. However, as with all features and development, updating one part highlights issues within an existing part. The Embed Image function of the RCE needs to be made consistent with the Accessibility Checker and the new image uploading function. Add to this also when images are placed within the RCE by clicking their icon on the Images tab. Canvas should not automatically fill in the file name as the alt-text. How to prompt for an alt-text or to be decorative is something the UI folks will have to address.   I hope this gets the attention it deserves. It is a real issue when new features result in functionality that violates accessibility standards. ... View more

Could you please clarify the behavior of the links when a course is copied? For instance, I did a test by making two pages in a course, JLC Test, and JLC Test 2. On JLC Test 2, I made two links to JLC Test. One was direct, by selecting copying and pasting URL into the link dialogue box, and the other was through selecting the page in the side panel. The code was almost identical, with the exception of the inclusion of a title tag: <p><a href=" https://fsu.instructure.com/courses/24803/pages/jlc-test ">Test Direct Link</a></p> <p><a title="JLC Test" href=" https://fsu.instructure.com/courses/24803/pages/jlc-test ">Test Through Selecting Links</a></p> When this course is copied and imported to another course, are both links still updated to the new course #? Or perhaps I am not understanding this update. If that is the case, could you please give a concrete example of how Canvas has changed regarding links? Thanks, John ... View more