Yup it looks like your theme is inserting a gap between elements, so adding elements adds gaps:
.menu .primary-nav__menu-link > span {
gap: 0.5rem;
}
This would fix it:
.menu .primary-nav__menu-link.link-purpose > span {
gap: 0;
}
So; that extra markup is most of what this library does, rather than CSS ::after pseudocontent. The span wrapper prevents the link from breaking its line between the last word and the icon. But yes, sometimes themes need to style the icons to make the spacing match the text in menus, especially the icon width and height. This is the CSS provided by the library.
If you provide me a link I can take a look.
the_g_bomb → credited itmaybejj → .
I'm flagging this as fixed for now because of testing on a copy of your DOM. Please test 2.2.5 → with the new param "Auto-detect any Web components" turned on under "Web components and custom tests," and reopen if I haven't succeeded.
I have that param off by default for now until I'm confident it both works and doesn't hurt performance. This part of the code usually finishes in less than 1ms so I don't think it's going to hurt performance in any noticeable way.
Switching this to Fixed because I think 2.2.5 → will prevent future folks having the same headaches.
This looks fantastic to me. Thank you. Merging to test for next release...
Hello Nitesh,
I do not know how to provide a schema for a View. Could you assist?
itmaybejj → created an issue.
If y'all are up for testing something, I'm hoping MR 25 will take care of this.
It looks like pipelines failed on your suggested changes. Could you recheck those?
oh that's GREAT to hear! I'll keep focusing on general performance improvements then and not worry so much about testing against this site in particular.
After some more thought and testing, I think what I'm going to do is add some config for whether Editoria11y should watch the page for changes, and wrap most of the new code into that. That should give 2.2 a static running mode that performs like 2.1.
I should have a release ready for this in April.
Meanwhile -- see if that change works for you? It moves the message from the Help hook to the post_update hook, which only fires after the module is installed and the route exists. I hope...
Questions --
- There's no route named editoria.settings in the module repo -- is that a typo here in the queue, or is it possible there's a patch/typo in your dev environment?
- It looks like this fix requires the Help module to be both installed and configured? I'd rather not add that dependency if possible.
- I'm having trouble reproducing this. Is the install failing on your end, or is the install finishing and some local test suite is running before a cache clear and throwing errors in the console?
OK fair enough.
For what it's worth I asked the other maintainers to weigh in, and was reminded that they don't like that I automatically set permissions in the first place. Ahh well; it's the endless argument between "turnkey for most sitebuilders" vs "minimum viable install for developers." I'm biased to the former.
Glad you're enjoying it; it's a monster of a project!
I am afraid you are going to have to convince me it is a good idea to give a non-author role an elevated permission to view unpublished content they have authored. If they cannot author content, then there are no nodes for this permission to give them access to, which is why it is not enabled by default for non-editor roles.
So as far as I can tell the only non-authors this permission would make sense to give to would be people who were previously authors and had their author role removed, but you still wanted them to be able to view (but not edit or publish!) something they created but did not publish before they did whatever they did to lose access to the ability to create new content or publish that content. That seems...awfully unlikely, and far from least privilege best practices. Unless there are different use cases in play here I'm not thinking of -- e.g. some form of form-based content creation that non-authors can use where they need this permission?
...so that's why I have been using this permission so far as a proxy for "can edit stuff." It seems to be the only universal "can edit stuff" permission on the default list. The others aren't always enabled on all sites (can use toolbar, can use admin theme) or depend on particular content types being present...
...but note that it just adds the permission on first install. You can drop it on your sites if you want to keep your roles configuration as-is.
It only auto-adds permissions on install for roles that already have one of the following permissions:
if (
$role->hasPermission('view own unpublished content') ||
$role->hasPermission('access content overview') ||
$role->hasPermission('access in place editing')) {
$role->grantPermission('view editoria11y checker');
$role->grantPermission('mark as hidden in editoria11y');
This is my attempt to detect editors, not just authenticated users, so that the module "just works" for most sites immediately on install. Site admins can then remove the permission if they do not want it on a particular role.
Do you have one of those permissions assigned to non-editors?
Since I need to rewrite the backend anyway to take part in the dashboard initiative, I think I'll work on that first -- once all the data in the dashboard can be fully parsed by views, I can replace those links with a dependency on Views Data Export → , which has all that code already written.
In the interim the easiest solution would probably be getting a count of the rows, and then exposing a filter to download some reasonable number per report.
But I don't think I'm going to work on either solution myself until I finish the backend rewrite, so I'm going to mark this postponed unless someone wants to contribute a merge request.
Interesting. This might work.
I'm on assigned projects pretty much to the end of the month, and will be turning back to this March-ish.
Oh that's a great idea. I should add that too.
Editoria11y also flags alts that are suspiciously short, suspiciously long, contain common placeholder text for validation evasion or trim() to 0 length if you remove unpronounceable characters like "?,.'. The first two are "soft" alerts, the latter three cannot be dismissed.
If you are validating server-side, you could potentially OCR the image as well and flag images of text. That's too computationally heavy for me to do at runtime.
The menu seems possible. And it is outside main, so hopefully Editoria11y's mutation observers are ignoring all those changes.
The one clear takeaway I see so far is that I should make Editoria11y inherit the query token from Drupal for the CSS file rather than using its own version number; that should guarantee that the CSS preloads with the document before initial paint, so there is no second network call.
Oh that's clever, and will work fine for the life of the 2.x branch. Sa11y does something similar, just embedded within the rulesets.
My vague plan has been to use an array like that, but reversed (disallowedTests), so that people would not need to update their settings when I added new tests and there wouldn't need to be as much data in drupalSettings.
Great!
Yeah I'll leave this open so I remember to include this in the next release.
the_g_bomb → credited itmaybejj → .
Oh dear; looking at this...I think I need to update that documentation, because the library is aggregating the minimized JS file now, so doing it that way is going to get more complicated...
If you only need to override one, it would probably be easiest to just to override it at runtime; this could go in any theme JS.
// Listen for event
const overrideEd11y = function() {
Ed11y.M.linkNewWindow = {
title: 'Manual check: is opening a new window expected?',
tip: () =>
`<p>Readers can always choose to open a link a new window. When a link forces open a new window, it can be confusing and annoying, especially for assistive device users who may wonder why their browser's "back" button is suddenly disabled.</p>
<p>There are two general exceptions:</p>
<ul>
<li>When the user is filling out a form, and opening a link in the same window would cause them to lose their work.</li>
<li>When the user is clearly warned a link will open a new window.</li>
</ul>
<p><strong>To fix:</strong> set this link back its default target, or add a screen-reader accessible warning (text or an icon with alt text).</p>
`,
},
document.removeEventListener('ed11yResults', overrideEd11y);
}
document.addEventListener('ed11yResults', overrideEd11y);
I'm not working on anything tagged "postponed" at the moment.
Oh yes -- don't worry about selectors for the admin theme. If Editoria11y detects editable content it swaps out that parameter for its hard-coded selectors for CKEditor and Gutenberg instances...and it doesn't render on admin pages if it doesn't detect editable content.
Oh and -- config: content_root: '#main, .block-system-main-block' -- I'm looking at your site and those selectors are nested. Editoria11y does not like content roots being nested within each other. Can you knock one of those out?
Oh that makes me want to cry. I used to inline all my CSS until the CSP module folks ✨ Support Content Security Policy (csp) Needs review asked me to abstract it out, and remote CSS calls are thread locking. But still; those late CSS requests should be served from cache, so only the first should slow you down, which makes me wonder if something is running for 55 seconds before the locking request is made. What I really want to see is the JS stack chart for those 55 seconds.
eeeeven more diagnostic questions:
Do you see the same problems while editing pages (backend theme) or only frontend pages?
On the frontend when you are seeing issues, what is the value of Ed11y.options.inlineAlerts?
Oh that's very helpful. We all run LastPass too. I'll see if I can figure out how to record and trigger that.
Yeah that might do it. I'm on project work for the next week but I'll give it a spin when I come up for air.
Hmmph. That config should be fine.
I was able to grind my browser to a halt on one page on the frontend. I don't know if it's the same cause, but there it seemed that Editoria11y and Qualtrics were fighting with each other -- page interactions were causing Qualtrics to tie up the main thread, right when Editoria11y was trying to run. And since Editoria11y was asking for animationFrames to try to move its tips to sync with page scrolls, this was leading to more than one second of jank:
Are you perchance running Qualtrics metrics on the backend as well as the frontend? If so, do the problems go away if you set it to only render for anonymous users? Editoria11y 2.1 did not have the mutation observers to check for changes to the page, so it would not have been trying to run at the same moment during page interactions.
I can remove the animationFrame requests and see if it improves anything, but since JS is singlethreaded I doubt that will make a difference; any activity ties up the thread. I think something bizarre is going on, like a memory leak of some sort. I'm very puzzled, because my browser would still be lagging heavily even though the performance monitor was not showing any JS activity.
I have to set this aside for the moment because I am not sure what to do next, but I am going to keep this bug open until we figure it out.
Which site is this for? I'd like to look at the markup. Also, could you send me → a copy of your config settings? I have seen some situations where certain settings can add up to a lot of drag.
I performance test on synthetic pages with hundreds of issues and a literal copy of Moby Dick, so if you are having any performance issues it is a bug, and I would like to troubleshoot. 2.2.x should not be slower than 2.1.x. The one thing I can think of that has changed are some mutation observers -- if you have mouse hover based attribute changes in the DOM it is possible something is thrashing....
Oh my goodness; this is the first time I've seen a nested Web component. I think both my element finder and name computation only recurse once and will need to be rewritten. I'll reopen this issue.
Sure, if you're thinking more along the lines of input validation than maintenance down the line.
Marking fixed for now. Please reopen if you notice issues.
Although if I took that route -- I have often thought about creating a browser-based simple crawler for Editoria11y, that just creates a grid of iframes and runs through a sitemap, with a shared Worker thread in each iframe phoning home to tell the controller when it has finished loading so the next URL can be requested. That would allow for any number of browser based checkers (e.g. AXE core) to run without hitting the server. But oh goodness the load it would create, as every request would be uncached and include JSON hits with the result.
It can be done for sure -- just make AJAX calls and report errors...but it would be less effective and more work in my opinion -- links often go stale on pages you are not viewing, so link checking is usually done by crawling rather than live checking. And then to keep the load down on the server and the browser, I'd want to create a table of every found link and when it was last checked...
Oh I'll also say since you mentioned SI -- I am also looking into doing this using the API from our third-party solution. E.g., piping the broken links it found into the Editoria11y interface, so editors can view all their issues from any source via Editoria11y's UI.
Ideally I would love to just have a bucket of connectors in the module -- LinkChecker, SiteImprove, DubBot, etc. There would need to be a lot of filtering though -- a lot of issues from the "bigger" vendors are irrelevant to content editors. So I'd only want to pipe in a few relevant tests.
Longer answer sent privately, but for the record:
For Drupal, I would want to filter it to relevant things for the current page, like I do for the dismissals on the page.
That array is just slapped into drupalSettings at line 343.
For broken links, the first thing I would try is building a selector – performance testing would be needed of course. E.g., ‘a[href=”example1”], a[href=”example1”]’. And then pass that to the native finder function:
Ed11y.findElements('error404','a[href="example1"], a[href="example2"]');
Ed11y.findElements('error403','a[href="example3"], a[href="example4"]');The rest would follow the pattern from the safeLinks test -- add each of the found items to the results array, and provide the various strings needed to build each type of tip.
Honestly – the Editoria11y side of this is really easy for me. The hard part for me would be rooting around in LinkChecker’s tables to shove the list of broken URLs on a route into drupalSettings somewhere. If someone took that on, I could do the rest.
Much progress! 1-3 are done, and yes some users have already used them to write connectors for the library in other CMSs.
I definitely will not be writing my own link checker. It's just too far outside my expertise, and my employer already pays for a vendor tool.
The next thing I'm going to work on is rewriting my database tables to have more robust node references. If I get that working it should make connecting with other modules via the dashboard initiative much easier.
It will probably take me a year to write all that myself, but the pieces are in place for someone to contribute connectors with specific modules quite easily before then if they have the time; I'd be happy to show them how to do it, and I have some code samples users have sent to me over the years.
Me too. Unfortunately I do not think it is possible with the current database tables using Views -- I originally implemented my "Entity ID" field in a way that conflated NID and TID. It is my hope to write some hooks to rewrite my tables and make this possible later this year as part of 3492299: Add full views integration for the content dashboard ✨ Add full views integration for the content dashboard Postponed .
I do think a custom entity query could do it in the interim, by writing a JOIN against the node and Editoria11y tables, and filtering the Editoria11y tables to only include nodes.
Looks like 2.2.3 is up and ready with all the new strings. Is it ok for me to mark this fixed?
Huzzah! Thank you for finding and testing.
Please test 2.2.3. If you type "Ed11y" in the console you can see if the library is loaded. It should not be present on the Layout tab.
If your editing environment loads Layout Builder forms on other routes, it would help me to know what the route names are, and/or what CSS selector reliably detects your forms.
included in 2.2.3
I realized -- even though I was not initializing the library on Layout Builder editor routes, I was still attaching the library. It doesn't do any harm to be there if the auto-disablement works, but it's needless. This commit will prevent it from even attaching to those routes.
I'll keep this open until l.d.o gets the new strings then. I'm assuming there's nothing I can do at my end to help with that?
That's...profoundly troubling. Editoria11y is supposed to disable itself if it detects the Layout Builder editor interface is present on the page (.layout-builder-form) -- I learned during the beta that Layout Builder has scroll listeners that make it incompatible with another module modifying the page markup -- it results in what you describe. Something is very wrong if Editoria11y is running while Layout Builder is open.
Could you tell me what Editoria11y version you are on, what version of Drupal core you are on, and, if you are up for checking your browser console, whether anything is found if you type document.querySelector('.layout-builder-form')?
Oh -- so those placeholders are gone now, so it is just outputting %headingExample as plain text. The text that used to be %headingExample is visible in your screenshot -- it is the nested bullets.
I don't actually see the new strings on the translation server yet. That example should now be made of 4 separate strings, with no placeholders:
headingExample : `
<ul>
<li>${Drupal.t("Heading level 1")}
<ul>
<li>${Drupal.t("Heading level 2: a topic")}
<ul>
<li>${Drupal.t("Heading level 3: a subtopic")}</li>
</ul>
</li>
<li>${Drupal.t("Heading level 2: a new topic")}</li>
</ul>
</li>
</ul>`
,
headingEmpty : {
title: Drupal.t("Heading tag without any text"),
tip: () => `
<p>
${Drupal.t("Headings and subheadings create a navigable table of contents for assistive devices. The numbers indicate indents in a nesting relationship:")}
</p>
${Ed11y.M.headingExample}
<p>${Drupal.t("Empty headings create confusing gaps in this outline: they could mean the following content is still part of the previous section, or that the text was unpronounceable for some reason.")}</p>
<p>
${Drupal.t("<strong>To fix:</strong> add text to this heading, or delete this empty line.")}
</p>`,
},Right you are. Tagged in 2.2.2 → .
Should be fixed in 2.2.1
Hopefully all fixed in 2.2.1 → , and I added a debug parameter to make it easier to review in the future.
I'm going to do both-- I'm reformatting the strings to support Drupal.t() for all languages. But people also use the library on other CMS platforms. And any languages I have natively supported in the JS library I don't have to pass through Drupal.t().
I hope to finish today or tomorrow.
I will keep working on breaking up the strings then, since I know that will work.
The other translation option is to add a DE object to the library languages file. That would be much more robust between versions, and I would then just use the library translation rather than Drupal.t for the JavaScript strings.
Question -- did you have this problem in 2.1? I could revert most of these strings to what they were in 2.1 for now, which would restore existing translation work.
Alright; I wrote some tests to compare strings and confirmed that most of the missing strings are due to HTML tags in the strings. This is definitely going to take me a few days to fix.
The good news is I can reproduce the issue.
The bad news is that I do not understand where the problem is coming from. These strings are available for translation, but I think I may have HTML in these strings that is causing the Drupal.t() function to ignore them.
I hope to have a fix to you this week, but I am concerned I may need to break up a lot of strings into individual sentences, which will be very time consuming and break a lot of existing translation work.
Indeed. The tip dialogs do need to paint over the interface, but the tip marks don't necessarily. Playing with Gin Toolbar, it looks like setting the z-index param to precisely 491 might give what you are looking for on the frontend:
...that does run some risks, as absolutely positioned elements could end up with marks being hidden entirely behind Gin. But that is rare, and you could still get to those marks via the "next tip" button on the panel.
But on the backend...the backend is so much more complicated. Here we have frequent situations where the marks partially intersect the Gin components (to get them off the text someone is editing), and at certain breakpoints CKEditor floats the interface. Using 491 (so the two elements are 501 and 502) can make it so CKEditor draws on top of Editoria11y dialogs, which is no good:
...and unfortunately Gin's left and top bars are set to 501 and 502, so there's no number between them I can use.
In an earlier branch I had separate settings depending on whether CKEditor was present on the page. This is easy, as they are all inheriting a CSS variable that can be changed at will. I could go back to that, so the overdraw would only happen when there was a CKEditor frame under the toolbar -- the marks hide when scrolled out of the visible part of the CKEditor frame.
Otherwise -- I think I would need Gin (and Drupal core) to change so that the vertical sidebar and the top toolbar had a z-index value available between the two -- 501 and 503 rather than 501 and 502. But I'd be surprised if people were willing to make that big a change. It would help me and possible other modules though...
Also fixed in 2.1.22.
Fixed in 2.2-RC10. I'll backport this next time I refresh 2.1.
OK I've added the ability to read text in slotted templates and added this case to my automated testing.
I am going to wait until January to tag a release though just in case this breaks something unexpected.
Yeah; Editoria11y and Sa11y are running a homebrewed abbreviated version of the accessible name algorithm that roughly matches markup that is possible to create with CKeditor and Gutenberg. Haven't added slot name computation yet.
It won't be hard. I'll look into wrapping it into the next release.
My suggestion is to simplify and get rid of the live audio feedback altogether:
- Just toggle an aria-invalid attribute on the field. Don't try to associate it directly with the dynamic suggestions.
- After the field, where you have the validation error -- "Password does not meet the site requirements" -- make that a details/summary tag rather than plain text. That way the validation error, if present, will be the summary -- the next item in the tabindex for screen readers to find -- and users can choose to show the live validation list of remaining requirements in the
<details>if they want.
This stumped me on Editoria11y. I'm currently doing this wildly inelegant thing to get the true alias:
$page_path = \Drupal::service('path_alias.manager')->getAliasByPath('/node/' . $nid, $language);
$lang_check = Url::fromRoute('<current>')->toString();
if ($language &&
str_starts_with($lang_check, '/' . $language . '/') &&
!str_starts_with($page_path, '/' . $language . '/')) {
$page_path = '/' . $language . $page_path;
}
The alias manager will get me the "nice" alias...but not reliably language prefix. Url::fromRoute will get me the prefix, but not the nice alias. So I have been running both queries and prefixing as needed.
Merged and released → . THANK YOU.
Thank you. I'll get this merged and released by tomorrow morning.
itmaybejj → created an issue.
Fixed in 2.2 branch.
Another way to address the accessibility issue may be to have some sort of "are you a human" field that a user can interact with, and disabling the submit button until the user has passed any tests.