I've had...less embarrassing moments. 2.2.13 tagged → .
Thanks for posting the workaround; I'll take a look at this in the next release cycle.
Possible hints if anybody wants to take this on:
- Views itself has a wildcard schema for views? and data types
- some documentation → that of course does not mention Views, but presumably it's a config type
I'm working on this in a 3.x issue fork.
OK I'm convinced. 1.0.19 removes the parentheses. →
If it works on your project I'm satisfied. This basically removes all the new code in the PR and replaces it with a simple "If the bundle is missing a label just use this hard-coded string instead." I don't expect that to introduce regressions
Updated MR !32. See if this works.
$entity_type = $entity && method_exists($entity, 'bundle') ? "Taxonomy: " . $entity->bundle() : 'Taxonomy term';
I'd vote to keep the H2. Sub-themes might place this block in other regions.
Thank you. The smaller viewport attribute is probably going to solve a longstanding bug where the icons sometimes paint oversize for a single frame while the CSS is loading.
That looks good to me. Let me do some testing against some past edge cases before tagging a release.
Thanks. This will be an easy change but it's nice to able to test.
Finding out "what is this thing and what is its name" is startlingly complicated in Drupal, and edge cases in custom entities are common.
Reading up on this; it sounds like JAWS pronounces them at certain verbosity settings? Is it in JAWS where you are hearing it?
I have been testing in NVDA and VoiceOver, and in both of those it sounds more natural to drop the injected text into a parenthetical clause. I could probably achieve a similar audible affect using commas, but I'm trying not to mess with the actual grammar of the surrounding sentence...
It would certainly be easy from a technical perspective to expose these settings in config -- these strings are all passed to the library as options. But I'd rather have the base library have defaults that satisfy the majority of the people who are going to benefit from it.
I might have to reach out to some JAWS users for feedback; the more the merrier for this sort of thing...
Yeah I'll work on this in the 3.x branch. That will have a beta period that will be good for feedback.
itmaybejj → created an issue.
Good feedback.
The proposed change is almost sounds awfully like something I iterated through during development. I went rooting around and found these early screenshots:
I thought the arrows were ambiguous -- they seemed unclear as to whether they would "dock/close the interface" or "go to next issue." I myself switched what they did a few times in those iterations. It also wasn't clear that the number was a count of "problems on the page" rather than, say, message notifications -- it seemed too easy to ignore. I gravitated towards having the number and the alert flag visible because I thought it was more eye-catching to have the flag come and go.
Another consideration...you can open and shut the checker even when there is no flag, so it seemed natural to use main toggle as the "next" rather than the number; otherwise I would need a third "power" icon.
Although in looking through old screenshots...I do not know if I explored another direction -- switching the position of the number and the flag. That would let the number increment to the next issue. Roughly mocking that up now, it could look something like:
...thoughts?
Hopefully 1.0.17 solves this for you → .
Publishing your solution as a sidecar module is PERFECT, because it introduces some dependencies that I would not want in the main module. This is where I was thinking of going myself with other integrations.
I figure what I'll do is edit the project page to highlight this and other "connectors" as they appear.
One thing you may want to consider is letting authors dismiss these alerts if SiteImprove is wrong -- if you wanted to do that, you would add a dismissal key when you push the result. Instead of:
dismissalKey: false,
you would use:
dismissalKey: Ed11y.dismissalKey(el?.getAttribute('href')),
Config to turn off checker while editing should work correctly in 2.2.9 → .
itmaybejj → created an issue.
Oh goodness; neither config is working right any more. I will try to get a release out tomorrow with bugfixes.
Yes; I agree that this is confusing in the UI at the moment.
It looks like it would be possible (though complicated) to modify the library to check inside closed tabs provided by the Field Group module → , as that module does render the field content in the DOM even when hidden. I would need to modify some of the parameters at runtime so that it does not ignore these hidden elements, would need to add a function to hide the tip toggles from results in any hidden tabs, and add a function to ask Drupal to switch tabs and then rerender my results with a different set of hidden tip toggles if someone hits "next" into an alert on the hidden tab.
It looks like it would not be possible to modify the library to check inside closed Paragraph → tabs, as Paragraphs does not render the DOM until a tab is opened.
I'm...honestly not sure what makes sense to do here. I'm trying to be consistent, so I do not like the idea of the module working notably different depending on the fields present on a content type. And Princeton does not put CK content inside Field Group tabs, so I am not sure they would want to sponsor the amount of work involved in something for only that use case.
Alright; I'll have to add a config field for selectors for elements to not receive the Nobreak. That should be easy enough, and parallel the config fields for links to ignore or links to not show the icon at all. I don't see any practical way to make a Nobreak compatible with someone applying a CSS gap on the contents of a link.
But this CSS gap declaration -- where is it coming from? I don't see it in Olivero, only Gin. I like to support common themes/modules out of the box.
I'm afraid this is controlled in the user's browser preferences, and is not a feature of HTML. Links specify they want to open in a blank context, and the browser decides if that will be a new tab or window.
It is possible for JavaScript to attempt to force a new window, but this is such unexpected behavior that browsers block it and throw a toolbar alert asking a user to permit the site to open popups.
Now...it's been a few years since every browser make switched the default from Tab to Window, and very few people know they can go into their browser preferences to change it back, so perhaps I should change the default wording in the config to Tab instead of Window...
ack; will fix
Oofta; found a real issue in the wild. The caps lock test is escaping confinement.
Summarizing notes from Slack conversation --
VBO does an odd thing where it has an unlabelled checkbox with a title attribute as a pseudo-label. This is...not a best practice...but is technically permitted under the accessible name computation. So this is a false positive; the VBO markup is OK.
The challenge here is that the accessible name computation has a lot of steps, and running it all on every element on a page would introduce jank, so Editoria11y and Sa11y only run a subset of its possibilities, based on what is generally possible to create in CKEditor and Gutenberg.
I need to ponder this for a bit and decide whether it makes more sense to add this to our computation, or just add default config to automatically ignore VBO tables. I have seen a similar issue in some Webform tables.
For the moment, users can add VBO table classes to their Editoria11y config for elements to ignore. Editoria11y is only testing tables for headings and headers, so this is unlikely to create any false negatives.
That was my assumption as well, but 🐛 Allow PHP 7.4 when using 2.x Fixed have shown me 🐛 Error: Class "Drupal\Component\Utility\DeprecationHelper" not found in editoria11y_page_attachments Active .
I'll have a branch tagged with this by 🌱 Drupal 12.0 compatibility planning Active , when modules are expected to begin preparing for Drupal 12.
I am hoping this is the last time I need to revisit this for the Gin toolbar and the Drupal modal, but I absolutely expect this issue to resurface with other modules. This time I left a lot of notes-to-self, in hopes I don't break Gin again when I address the next round of surprises.
This change breaks compatibility for 128,000 core installs → (9.x through 10.2). I can't do that in a minor point release.
I am keeping this in postponed until I release a breaking release with new version requirements or Drupal 12 alpha is tagged, whichever comes first. I hope to be ready for a breaking release thus summer or fall, with new DB structure and views integrations.
That...should work.
I added an event to the library for when tips are drawn, and use that to iterate the results and modify their z-index. Now only the Editoria11y toolbar, active tips, and tips on content in a modal should draw on top of the Gin toolbar.
And since I was revisiting Drupal's modals anyway, I added some logic to detect when Drupal opens a modal, which temporarily overrides the check roots to only check within the modal and then re-runs the checker. I figure there's no sense tagging things behind the modal, since you can't get to them until the modal closes. Maybe someday I'll generalize that for any opening modal dialog.
I'll wait to tomorrow to tag a release.
Oh dear you're right. I have competing problems I'm trying to solve here. I'll reopen/revisit this.
3521111 is unrelated; that just added the right-side toolbar to the selector list, so that the Editoria11y toggle will pin to the Gin toolbar rather than the left edge if someone sets it to pin left instead of right.
Pulling out of postponed to integrate into spring/summer work.
Pulling out of the postponed queue to add this to my spring/summer task list.
itmaybejj → created an issue.
If you would like to recheck, I have merged in some recent changes and fixed some issues in the CSS and API.
Oh good; that's what I was hoping because all other possibilities were going to be "exciting" to try to troubleshoot.