Markdown Accessibility dev-tools

I am working to create a markdown dev-tools validator. The validator will check any textArea that:

• is not hidden on the screen i.e. clientWidth=0
• has content i.e. value != ''

Working Rules

• checks that written markdown has a heading
• ensures that written markdown does not use an h1 tag
• ensures that written markdown includes descriptive links

Features:

• On non-github pages the validation Button and the reset button are disabled.
• The reset button will clear all of the error messages, and remove any added focus rings.
• The Find TextArea button will highlight the markdown field that the error stems from

A snippet of what the markdown dev-tools looks like:

Questions:

• not sure If I we should be using the Mona illustration

Future TODOS:

• I would love to use primer components and replace a lot of the styling in panel.css
• We should internationalization the non-descriptive link text array so users who do write their markdown in english can also use this feature.
• validate image alt text
• Report bugs individually. For example we report the "Non Descriptive Links" error once ... even if multiple links are not descriptive but it would be nice to report each link individually to provide more descriptive feedback.

Fixes: https://github.com/khiga8/github-a11y/issues/28

• [x] account for images which are typically wrapped with an anchor tag.
• [x] account for new GIF player and ensure overlay properly appears ~~(which is an img but has a button parent with aria-label)~~

Sadly, due to Firefox still plugging away at Manifest V3 support, it's not too thrilled about loading this extension. https://blog.mozilla.org/addons/2021/05/27/manifest-v3-update/

I wanted to make sure that we had no extra or excess formatting changes on future prs.

• Prettier will format the files
• and husky ensures that prettier runs on and changed file right before a developer commits the changes

This PR makes a couple of updates:

• fix bug where page crashes when I go to Notifications from home page. This is a recent issue I've been noticing. I think there might be an infinite mutation loop happening when I go from GitHub home to Notifications. I am unable to hit a breakpoint when I try to debug, but adding observer.disconnect(); call within the callback fixes the issue.
• adds an interval to debounce making the appendAccessibilityInfo updates
• updates the selector we listen to from mutation.target.matches('.markdown-body') to mutation.target.closest('.markdown-body')

On GitHub, all images in markdown turn into links. Therefore, setting alt='' will never make sense because that results in a link being rendered without a name, potentially causing confusion. Our validation should account for that fact.

Fixes https://github.com/khiga8/github-a11y/issues/23

This extension started working only on page refreshes due to recent navigation changes. This adds an eventListener for turbo load events to ensure this extension works properly when turbo is being used.

For quicker visual processing, I think it's helpful to have each heading level represent a different color. Therefore I am making this the default instead of a single purple color represent all heading levels. If consumers do not like this default, they can choose their own customizations following instructions in the README.

I used http://colorsafe.co/ to vet out colors that meet WCAG color contrast requirements, but some may find these colors unsuitable.

Fixes https://github.com/khiga8/github-a11y/issues/17

This presumably has to do with how content of js-commit-preview changes and markdown-body is injected in as a child element. Not sure why MutationObserver doesn't have a mutation for markdown-body, but this fixes this issue in the interim.

I was working on a README update through web editor but the extension didn't run when switching to Preview tab.

Putting some print statements in, there is a mutation.target that matches .js-commit-preview but not .markdown-body even though the content of markdown-body changes. 🤔

Fixes https://github.com/khiga8/github-a11y/issues/12

Context

Previously the text overlay was styled to appear over the image. This resulted in text covering the image. Another problem was that when there were multiple images on the same line, the captions for each image will overlap on top of each other.

Instead, we have the text overlay appear below the image and a border outlining the image and overlay to group it together. Additionally, we ensure that the alt text overlay is added when image is nested inside table and other elements, not just <p>.

This also turns off the extension outside of the github.com and gist.github.com domain where support may be wonky.

Screenshots

Before:

After:

Relates to: https://github.com/khiga8/github-a11y/issues/44

When images are wrapped in a link:

• Don't allow alt="" ever
• Check if link has aria-label or aria-labelledby

When images are not wrapped in a link:

• Allow alt="". Indicate that the image has been hidden.

Currently we report the "Non Descriptive Links" error once ... even if multiple links are not descriptive. We should report each bug individually to provide more descriptive feedback.

example

This markdown:

<a>Learn more</a>
<a>Click here</a>

Should output two non descriptive link errors -- right now it will output one.

Acceptance Criteria

• [ ] - each rule break is reported individually
• [ ] - a user can tell the exact link that is being broken. Perhaps this means adding a message "Link on line 10 is needs to be more descriptive.."

Add a rule to validate image alt text inside the devtools suggestions.

Acceptance Criteria

• [ ] - does a user add alt text
• [ ] - is the alt text empty (this might be a warning instead of an error)

We should add Internationalization throughout the chrome extension. I.e. We should have our chrome extension switch languages depending on user preference.

Acceptance Criteria

• [ ] The list of non descriptive link text changes with users language preference
• [ ] Our feedback changes with users language preference
• [ ] set the default language to english

We are rewriting css instead of using primer components -- this will lead to issues down the line if primer has a redesign. It would be nice to use primer components to avoid future issues and keep consistency.

We may need to spike this idea out. I am not actually sure how easy it is to use design system components inside a chrome extension since importing in a chrome extension is challenging.

Acceptance Criteria

• [ ] Replace buttons with primer button
• [ ] Replace links with primer link
• [ ] Utilize Primer color values