🇺🇸United States @itmaybejj

If it helps -- the 2.2 branch → with the as-you-edit checker now includes default config that will ignore the same page preview frame and live-check the CKEditor fields instead. It also moves the panel over off the preview pane into the editor column. And it avoids covering the Klaro dialogs.

New bugs always show up.

Drat -- reopening this as the fix caused a regression that prevents populating reports for sites that are installed in subfolders.

@lily.yan this fix is also now in the 2.2 branch. →

Ok -- 2.1.20 → should work for you.

Oh lovely. The deprecation "helper" to make it easier to handle deprecations crashes Drupal prior to 10.1.

Tagged 2.2.x Beta 3 → . Unless new bugs show up, I think this is ready for release.

itmaybejj → created an issue.

Thanks heikkiy.

From rkoller in Slack:

[...]on large screen monitors the editoria11y widget in the bottom right corner of the screen is located quite far away from its context (the wysiwyg field ) you as the user are working in. so you have to jump visually between the wysiwyg field (if you want to check the remaining number of errors for example) and the widget [...] i wonder if it would be possible in case of the wysiwyg integration to add some sort of status bar at the bottom of the ckeditor field containing the functionality and information of the widget.
That would also benefit in regards of the position in the DOM. at the moment the elements contained in the widget are at the end of the DOM move to some sort of “(status) bar” underneath the ckeditor textarea, these elements would also be right next in the for example rotor list in voiceover?

[...] you can have the case that a content type has more than one long formatted text with summary. but editoria11y is still displaying the overall number of errors for all available ckeditor fields on the node edit form. i am not sure if it would be desirable to distinguish between ckeditor fields in that summary or not, or if it should be configurable, or if there should be an option to have separate status bars as suggested in the previous point for the different ckeditor fields.

[...] if you expand the widget and you have a low number of errors the widget turns yellow. the collapsed circle has a blackish outline within therefor it is easier to spot but that expanded state is yellow only. against white background the color contrast for yellow is only 1.4:1.

[...] i was testing the new recipe for the [StarShot] privacy track with the latest version of drupal cms. [...] the module shipping with the privacy module has also a widget that is shown in the bottom right corner of the screen. on wide viewports editoria11y is hiding the button

Summary of tasks resulting from feedback so far

1. Continue work adding next/previous buttons to tips to reduce eye travel, and restore missing transfer-keyboard-focus button.
2. Add manual and offset parameters with automatic detection of Starshot module widgets.
3. Considering integrating main toggle into CKEditor toolbar instead of showing it at all on admin pages, or somehow pin to each editor instance.
4. Consider appending tips right after the contentEditable region rather than at the end of the body, to ease keyboard access. (note that I might punt on this until after Gutenberg integrations are done; some functions assume tips are still present, and other scripts modifying the wrapper might break that)

Revised tip for beta 2 incorporating @heikkiy suggestions:

It's working!

itmaybejj → created an issue.

I'd love to see it when it's ready; I'm all for making the default dashboard more useful, and for documenting ways to extend it.

Hi Damien,

I'm having trouble reproducing this problem -- is it visible when you have Claro set as your admin theme and then disappears when you switch to Gin, or is it always invisible for you? It should only be rendering on the frontend theme, so installing it in line with Gin shouldn't affect it.

Also -- do you have any Gin extras running that allow for live inline editing? If something is rendering contentEditable elements inline, Editoria11y may be preventing itself from rendering to prevent corrupting editable data. The 2.1.x branch will only render on static pages -- 2.2.x (coming soon...) will also be visible when editing content.

Usually the first step is figuring out where it went...

1. If the module thinks it is on an admin route, or the page is being viewed by an anonymous user, or the page is being viewed by a user without the "View Editoria11y checker" permission, it will not run at all.
2. If it detects a selector that prohibits running (editable content), it will not run, but it will throw a warning in the browser console: "Editoria11y is disabled because an element matched the "preventCheckingIfPresent" parameter"
3. If it renders just fine but a theme element is covering it, if you inspect the page, you should find a "ed11y-element-panel" tag as nearly the last element in the body. You can then play with the CSS and see whether something is z-indexed in front of it or overriding its opacity or something like that.

Editors gonna edit indeed.

I could add a routine to drop records of hiddens when something is marked OK. It makes sense to keep storing multiple hiddens against the same issue, but not a hidden and an OK...

Of course, if I stop storing that, someone marking OK and then reverting the OK would purge those hiddens for everyone, which could be handy or confusing...

......this is why I'm so afraid to touch this part of the logic 😆

If I am understanding you correctly -- that you want the dashboard views to not include dismissed results in the issue counts -- the views should already be behaving as you describe, provided people are using "Mark as checked and OK" to dismiss alerts they have reviewed. The mark OK button records the dismissal and decrements the number of issues found on that page in the results table.

The "Hide alert" button only ignores it for the active user, so it remains visible in the result counts.

The reason you are struggling with creating views is that individual result counts are not recorded at all -- the only thing recorded per page is a count of each type of issue that has not been marked as OK.

If that is confusing -- you can control the ability to "mark OK" and "mark hidden (ignore)" by role -- so you could just turn off "mark hidden" on a site and only have one button. It's...possible that would be a less confusing default configuration for the module...

Oh one last note -- ideally, if you are able to add JS to the site, you can get rid of these alerts altogether by automatically opening elements to reveal the hidden content with the error before Editoria11y runs the hidden check.

Oh I like this idea.

I need to rewrite that whole part of the code as part of the CKEditor integration rewrite, so I'll add this to the queue for that.

Looking this source code over (have not pulled a test environment) --

I would not drop aria-describedby and aria-labelledby if the targets are rendered on the page. I see your logic, but if those attributes are present for some reason, won't they be equally needed in the duplicate?

Also -- I'm assuming if there is no aria-label on the source, this code won't put that attribute on the target, as opposed to putting an empty aria-label? I've seen the latter sneak through now and then.

And last -- aria-details does not have widespread support. It doesn't hurt to copy the attribute, but developers really should not be using this attribute in production code.

Oh I thought that happened automatically through commit credits

I'm closing this for now. The work it would take to add variables for all the strings to the GUI and map all those variables to the localization file is just out of scope for me. If someone wrote it, I'd review it.

At the JS level, the localization file can be overwritten with your own values. Or you can use the ed11yPop event to modify the rendered tips however you want -- e.g., by adding that help link.

That said -- the default language in the tips are just the result of this community winging it. I heartily welcome suggestions for improvement.

Fixed in 2.1.19 (hopefully) →

Fixed in 2.1.19 →

Fixed in 2.1.19 →

Fixed in 2.1.19 →

Thank you.

🤦

I'm closing this for now as it is working as designed; please re-open if I have misinterpreted.

...fwiw my prolonged silence is me wondering if I can be a little more lightweight here. This many cache tags down on a cache tag that is only set for logged-in content editors and only invalidated if someone dismisses a manual check (...rare)...it wouldn't be a big deal of a couple extra pages got matched for invalidation...so rather than using an MD5+b64 conversion, I could probably just change the string truncation from the first 1,000 characters to something like the last 20.

Thoughts?

I don't know how to hit the strings in config/YML, but hopefully this commit will help with the user-facing interface.

Out of curiosity if you know -- is the automatic word matching layer aware of context cues, or are they purely for the human translators?

note to self for implementation -- context syntax →

What is the markup being output? If all is working correctly:

• no alt attribute: error, missing alt. Screen reader behavior varies, but generally speaks filename or file url.
• alt="" (empty quotes): warning/manual check for decorative image. Screen reader ignores image.
• alt="""" (quotes containing quotes): error, because this is not marked decorative, but rather is technically valid alt text made of quote characters. Screen reader announces that there is an image, but just makes an awkward silence when it reads the alt as it iterates through characters it does not pronounce.

Oof. So this module family creates a pseudo-multisite with multiple domains being served from one DB?

If that is the case, I don't think we should drop the domains from the url -- you'll want them later, to search and filter the API reports. Probably better to rewrite the not-much-better-than-a-placeholder Editoria11y API path validator to accept absolute paths. Maybe that should be replaced with a call to PathValidator or something like that?

This may have some downstream affects on the views as well; that would need to be tested once the API was accepting absolute URLs.

I haven't been able to reproduce this yet -- is it missing all <picture><img> elements on your site, or only ones in certain containers?

By default that particular test ignores the following containers in addition to any custom settings:
img[aria-hidden], [aria-hidden] img, .ckeditor img

Is there any chance the missed-missing alt matches one of those?

Thank you

Yeah I don't think I want to support this directly because it makes me nervous about the future of the data. E.g., uninstall the module and now you have images all over the site with a meaningless string in the alt field being printed to the frontend. Better to just write a good alt the first time, and treat a missing alt as incomplete content. Really very few images should be marked decorative.

That said-----you can select directly against the alt attribute itself in the ignore selectors: [alt="technical debt"]

Hi Bernard,

Have you played with Decorative Image Widget → ? That might fit your needs for the content editing side.

There is not a connection between the two, though -- the widget lets the author mark the image as decorative, but Editoria11y still asks them to confirm that the decision is OK once the image is in context on the page.

I do not have an exposed setting to remove that second check, but one could disable that second check by setting an ignore selector like img[alt=""].

I found additional problems that block disabled users, stemming from the same cause.

1. Screen readers are not reliably detected. Screen reader users can navigate without using the Tab key, and several navigation methods throw no JS events at all. So only meta keys may be received, or it's possible NOTHING will be received before other than a click on the "next page" button.
2. Voice control (dictation) users are not detected at all. The first event their browser fires is "click" on the submit button.

I pulled your patch into an issue fork and added some more:

1. Simple click detection to permit users relying on assistive technologies to submit the form. It's the only event that some browsers are going to fire I'm afraid.
2. Config settings to make the error messages customizable, so that real human users who are blocked for any reason can be given a fallback contact method, such as email or phone.

itmaybejj → made their first commit to this issue’s fork.

Fixed in 2.1.18 →

fix broken edudu link

We discussed offline; it looks like the issue isn't coming from the Editoria11y codebase.

itmaybejj → created an issue.

Oh and the other thing that would really, really help me would be seeing if there are error log messages at /admin/reports/dblog right after enabling the module. The one time I've seen something like this in the past was when a very particular PHP/SQL combination didn't like something in the table definition and refused to create the table.

That's...really quite troubling. I'd...assume at first glance that the module install hooks failed altogether, or that update hooks haven't run.

Could you tell me a LOT more about how I might set up an environment to reproduce this? Fresh install or upgrade, anything you can tell me about your host, and everything in "General System Information" under
/admin/reports/status

Feel free to email me if you don't want that public (jjameson at princeton.edu).

itmaybejj → created an issue.

itmaybejj → created an issue.

itmaybejj → created an issue.

2.1.13 →

2.1.13 →

2.1.13 →

I think this will fix the issue -- want to test before I tag a release?

I added a new, separate parameter, with a default value that should work when blank.

This should take care of it; do you want to test before I tag a release?

ok as I suspected. I'll see if I can revert that for a bit.

Hmm good find. Looks like I hard-coded the default strings from the ExtLink module rather than exposing a linkNewWindow parameter.

Lemme fix that.

oops sorry didn't mean to bump the status

This is huge; thank you thank you thank you

wonderful thank you

Here's my guess -- I'm studying that particular test, and as written it relies on a feature that was added to Firefox in version 119. The Firefox ESR channel is still pinned at 115, until sometime this summer.

I'm...hoping you can tell me that the affected Firefox version is 115.x.

If that's the case, we just need to decide whether to document this as a problem that will fix itself soon, advise y'all to add a[aria-label] to your ignore list, or have me remove the shorthand for the old verbose version.

If not...the puzzle continues, but I suspect the answer might be the same.

Thanks; that's enough information for me to be able to reproduce the issue. Lemme see if I can puzzle this out.

itmaybejj → created an issue.

It's true, but this is a regression that wiped out some seriously key stuff for onboarding new community members.

I guess if nobody else thinks this is worth fixing I'll just go into all the Drupal doc pages I can find that tell developers to read the render API pages, and change the links to point to the last-good d9 URL. That will create some terrible technical debt, but I can leave a list here so they can be changed back if this fixed.

On the accessibility question -- I don't anticipate an issue there. Assistive devices only need an HTML ID if something in the HTML is trying to reference the element by its ID, e.g. via a label's for= attribute or an aria-labelledby reference.

Sometimes in nav elements it's nice to reference the inner heading to give the nav a unique name. But that could be done in the JS with a simple global counter.

It's worth noting, if you are triaging docs, that a decent percent of the existing docs are broken 🐛 Classes missing from Drupal 10 Fixed .

I think it would help, regardless of what system we use, if there was a core documentation template focused on the person who is going to use but not understand the code. Write it for the new user. A lot of the existing function/class documentation is along the lines of "X: provides an interface to make an X."

E.g.,

1. Purpose of function
2. Example use
3. Links to extended how-tos

If that was templated, it might also help keep track of out-of-date documentation, since somebody doing a code review would see the URL that would need to be updated with the change.