#Accessibility

WOOHOO!

I think this would do the trick - https://git.drupalcode.org/issue/drupal-3083583/-/compare/11.x...11.x

but I'm not even sure where all of these forms are showing up to test.

We just ran into issue as well where our accessibility checks flag this. Will this be added in the next version update? Thank you for the work done!

So we need it for the Menu settings for node editing:
/node/2/edit?destination=/admin/content

I am not seeing a way to include the title here:
/admin/structure/types/manage/page/fields

This may not be the only place it exist, but I wanted to see some changes on this. We may need to refer back to this to remove other elements of the title text.

OK I'm convinced. 1.0.19 removes the parentheses. →

Yes. That sounds right to me. Using the same color would make it easier to identify. Thanks.

I think this would be better:

.ckeditor5-toolbar-item {
  border: 1px solid #8A8A8A;
}

.ckeditor5-toolbar-disabled .ckeditor5-toolbar-item {
  border: 1px solid #8A8A8A;
}

Hi,
I checked and compared the colors of both carets. The right caret has a color of #4F5661, which gives a contrast ratio of 7.4:1, while the left caret uses #8590A3, resulting in a lower contrast ratio of 3.22:1.

Just to confirm — would you like me to update the left caret to use the same color as the right (#4F5661) for consistency and better contrast? Please confirm so I can proceed accordingly.

I used the WebAIM Contrast Checker to verify the ratios.

Automatically closed - issue fixed for 2 weeks with no activity.

@kentr:

Thanks for the reply (here and on the related issue).

I will try to find time to add some tests coverage for this issue. From the comments, that is the only thing holding it back. (The Remaining tasks list "Update JS + templates". I think that is already done, although the current MR changes only one JS file, no templates. If I have that right, can someone that item?)

Two issues to address with this MR:

1. There have been other changes to the templates since this was proposed, so it needs to be re-rolled
2. The diff shows everything has changed, so it's extremely hard to evaluate the differences

I tried to update the patch here https://git.drupalcode.org/issue/drupal-867830/-/compare/11.x...867830-u...

The numbering may not matter, but because @lauriii is wonderful, the numbers aren't what I thought they were.

I think these are complementary issues, but definitely related.

Some of the icons also need attention for the "pressed" and / or "active link" states. Here's a screenshot.

@cwilcox808 said this RE forced-colors styling for the "pressed" state of the buttons:

For aria-pressed="true", you could maybe set border-color: Highlight;, buttons in that state wouldn't have a visual change on hover but focused buttons would still have the addition of the outline.

There was a solution implemented for canonical entity routes in ✨ Display content moderation state in the Navigation Top Bar Active which is worth noting here.

@vsujeetkumar it has been 2 years, so this will need to be re-rolled.

What comments are still unaddressed?

@pasqualle suggested an approach that @ricksta recommended. I think the summary there is new variable "status_marker" and mark the old ones deprecated.

We would need a new variable name I think.

@benjfisher

...@rkoller suggested using aria-pressed instead of aria-expanded...
Does that apply here? Should we consider it?

The place in the video that @rkoller linked is regarding a button that toggles light / dark mode. aria-expanded wouldn't apply to that, I believe, because in that use-case there's nothing to expand or show.

Later in the video, there's an example of a show / hide toggle button with aria-expanded. The video creator appears to approve of that use.

There's a separate question of whether to change the "label" (visual display) when the toggle is activated. I can't speak to that. I find changing icons for show / hide widgets (like the orientation of a caret) to be helpful.

When Javascript is disabled and those items behave as links, they still have role="button" and (currently) aria-pressed="false".

In this case, they may be wrongly announced to AT as buttons instead of as links. Attached a screencast of this in VoiceOver.

Based on a Slack discussion with @cwilcox808, I suggest:

1. Rendering these items as plain links without any HTML button properties (aria-role, aria-expanded, aria-controls, etc).
2. Adding those button properties in Javascript as part of the progressive-enhancement.
3. Adding CSS based on aria-role="button" that will style these as buttons instead of links when the progressive-enhancement has happened (both for full-color and forced-colors cases).

@cwilcox808 said this about the full-color styling and aria-controls:

I think that's a good idea independent of the forced-colors state, something like:

.toolbar a[role="button"] {
  text-decoration: none;
}

Instead of .toolbar .toolbar-item including text-decoration: none.

That does open up the use of adding the underline on :hover and :focus. I really like strongly associating underlines with links (behaving as links) so I'd like to see something else used when they have [role="button"]. Without JS, the line thickness could be changed, e.g.

.toolbar a[href]:not([role="button"]):is(:focus, :hover) {
  text-decoration-thickness: 0.1875em;
}

Note that only a single assistive technology, JAWS, makes use of aria-controls so it's not very useful. The better practice is to instead have the associated element immediately follow the control so users don't have to navigate through other content from the control.

@cwilcox808 said this RE forced-colors styling for the "pressed" state of the buttons:

For aria-pressed="true", you could maybe set border-color: Highlight;, buttons in that state wouldn't have a visual change on hover but focused buttons would still have the addition of the outline.

I know nothing about ARIA recommendations, but on #3286466-50: Tabbing order does not satisfy 508 accessibility requirements → , @rkoller suggested using aria-pressed instead of aria-expanded:

... But i wonder if aria-expanded is the right choice for a toggle button. I always have problem as a sighted user understanding the current state for toggle buttons that change their label inbetween states. A point that Leonie Watson also illustrated in their talk for smashing magazine: https://youtu.be/OUDV1gqs9GA?t=3222 . She advocated to use aria-pressed instead. That way the button state is either pressed/selected or not and the button label remains the same between states. That way things are completely clear and unambiguous for screen reader users?

Does that apply here? Should we consider it?

@andrewmacpherson: It has been more than 5 years since you self-assigned this issue and last commented. I am un-assigning it now.

Oddly, this issue does not show up when I search for "aria-expanded". Maybe that is because it appears inside a code tag.

If so, then it should show up now in the search.

This looks great.

Tested with geolocation module.

Automatically closed - issue fixed for 2 weeks with no activity.

Agreed with @eszszabo, this should really be solved in Core. Even Microsoft Word allows you to mark images as decorative, and surely Drupal is better with accessibility than Word. 😅

I merged the latest 11.x and applied suggestions.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

This is still an issue:

Yes the prefix and suffix were removed but just because it was coverted to html_tag

Thank you both. We'll try it on Sunday and submit a new ticket if we encounter any issues. Thanks.

Since there's been no follow up to above going to close out. If still valid please re-open with steps

Thanks for the prompt response! I will try out the new release and open a new issue if we encounter any problems.

Since there's been no follow up, going to close out. If still a bug in D11 please reopen

The MR contains lots of unrelated changes that need to be reverted first.

Hi heatherwoz, albertho425, thank you for your MR! I merged it and released Glightbox 1.0.18:
https://www.drupal.org/project/glightbox/releases/1.0.18 →

It looks fine for me:
https://drupalbook.org/ept/demo/video-and-image-gallery
https://drupalbook.org/ept/demo/image-gallery

Tested the MR locally. Borders now show properly in light mode, content area height matches tabs in dark mode. MR scoped to vertical tabs only. Ready to be RTBC.

@kthull failing an automated test isn't the end of the world. There are often false positives. Of course it is easier if the automated tests pass.

Interesting to consider though if role=status would be sufficient substitution. Worth looking into a bit more. Thanks!

Thanks @levmyshkin and @heatherwoz. I agree with Heather of using the ALT text from the image itself. In my case, images in Gutenberg are required for saving.

Having h2s prior to a page's h1 is not a big deal. In the case of messages, they're not really sub-sections of the page's topic anyway, right

Failing WCAG checks is the current issue I'm facing, so from that point of view, it's problematic. An element with role=status already gets announced as if it were aria-live=polite which makes the h2 overkill.

From Google search summary:

When a heading is not necessary
If the role="status" area provides a short, simple update that doesn't require further breakdown or organization (like a progress bar), a heading might be redundant or even disruptive to the user experience, according to MDN Web Docs.

When a role="status" message is intended to be self-contained and not part of a larger, navigable section, a heading might not be necessary, says the W3C.

Thanks @levmyshkin

That solution doesn't work for us, because captions are optional, and sometimes users don't enter them. They are also highly configurable by this module.

I think a better approach is to use the alt text from the image itself. Drupal includes an alt text field on its image fields, so we can reasonably expect this to be filled out. I have opened an MR to show what I am thinking. I also removed all the references to $data-gbox-img-attributes since that is not used with GLightbox the same way it was with Colorbox.

I'd vote to keep the H2. Sub-themes might place this block in other regions.

My inclination is to keep the h2s.

• Having h2s prior to a page's h1 is not a big deal. In the case of messages, they're not really sub-sections of the page's topic anyway, right?
• If the messages are contained within a named landmark (e.g. div role="region" aria-label="System messages", there's already semantics present that are useful for navigation. However, surveys show headings are used far more than landmarks by screen reader users for navigation.

I misunderstood the reason for using keyup with the space key.

I'll change it back to using two events and clarify that in the IS.

Thanks @siddharthjain_7998 & @jurgenhaas

I'll try to figure this out in the future.

This is looking good now, setting to "Needs review" so that people can test and review this.

@mgifford just FYI, the npm build command needs to be run in the Gin directory. But @siddharthjain has now done it for us, thank you.

Awesome, thanks so much @smustgrave!

Was literally in the middle of a 7.1.x release so I'll include..

Actually simple enough skip test

Fixes need to land in 7.1.x first and will need test coverage jsut FYI

Hi heatherwoz, albertho425, I added data-alt attribute in links with text from Caption. I'm not sure if you need additional separate field for alt attribute. Usually it should be enough to have something meaningful in alt="" attribute. And I removed aria-label from tag, it's not button or , so "title" attribute is enough for that. You can try dev version of the module or I will add a new module version later on this week.

Sadly, I need more information. This is a 3 line change (one little search/replace). npm build locally doesn't work for me Unknown command: "build".

It is a pretty trivial patch, but I still don't know how to contribute it.

diff --git a/styles/theme/variables.scss b/styles/theme/variables.scss
index 8e37e68b..ede2f940 100644
--- a/styles/theme/variables.scss
+++ b/styles/theme/variables.scss
@@ -12,7 +12,7 @@
   --gin-color-disabled-bg: #eaeaea;
   --gin-color-disabled-border: #c2c2c2;
 
-  --gin-color-warning: #d8b234;
+  --gin-color-warning: #9d6e04;
   --gin-color-warning-light: #efcf64;
   --gin-bg-warning: #{mix(black, #efcf64, 70%)};
   --gin-bg-warning-light: rgba(226, 151, 0, .08);
@@ -35,7 +35,7 @@
   --gin-status-bg: #eee;
   --gin-status-success-text: #1d6844;
   --gin-status-success-bg: #26a76930;
-  --gin-status-warning-text: #{mix(black, #d8b234, 40%)};
+  --gin-status-warning-text: #{mix(black, #9d6e04, 40%)};
   --gin-status-warning-bg: rgba(226, 151, 0, .15);
   --gin-status-danger-text: #cc3d3d;
   --gin-status-danger-bg: rgba(222, 117, 96, .15);
@@ -292,7 +292,7 @@
   --gin-status-bg: rgba(255, 255, 255, 0.12);
   --gin-status-success-text: #8bd3b1;
   --gin-status-success-bg: #26a76940;
-  --gin-status-warning-text: #{mix(white, #d8b234, 40%)};
+  --gin-status-warning-text: #{mix(white, #9d6e04, 40%)};
   --gin-status-warning-bg: rgba(226, 151, 0, .15);
   --gin-status-danger-text: #{mix(white, #cc3d3d, 50%)};
   --gin-status-danger-bg: rgba(222, 117, 96, .15);

I was unable to cleanly apply the existing patch file due to formatting and path issues, so I created a corrected version that applies successfully using Composer's patch workflow. I'm sharing it here in case it's helpful to others encountering the same issue. That said, since patch files are no longer the recommended approach for contributing fixes, it's generally better to submit changes via merge requests. I may submit this fix as a merge request in the future to ensure it's properly reviewed and maintained upstream.

There are a few code changes in the MR, but the most important one for this is this code --gin-border-color: #d4d4d8;
changing to --gin-border-color: #838585;

Just to compare the greys https://coolors.co/contrast-checker/838585-d4d4d8

The big thing here is that are these going to work in dark mode, and with forced-colors.

This is still a good idea.

As a start we could include it in the CKEditor Toolbar configuration admin/config/content/formats

Nobody is working on CKEditor 4 now I believe.

Very cool @itmaybejj

So we can close this when Editoria11y becomes part of Core?

@sandip that's interesting with the sticky header, but given that the sticky isn't visible, this is still a bug.

Is it better to loose the semantics by dropping the H2 or to retain the heading order? I'm not sure.

What else is needed to move this to RTBC?

@mgifford, basically two header is rendering in the table header one is the main table header and another one is sticky header. It seems like the tab is moving twice to the header but actually the tabbing is coming for both sticky header and original header. Some how using js i tried to remove tab effect for original header but in the radio button still the tab effect is there.

I am attaching an gif to prove that the double tab wave is occuring for two table header.

I have reviewed the merge request raised by @kentr, and it looks good to me. I’ve attached the before and after videos for reference. Additionally, I’ve added a log on click to verify that both the Space and Enter keys function as expected.

I am reviewing this

What's required is to run npm build locally in your dev environment. That will compile the changes into the distribution files and the result should then also be committed to the MR.

Automatically closed - issue fixed for 2 weeks with no activity.

I am also experiencing the issue where ALT text is not displaying for an image that has ALT text. In my use case, I am using it in Drupal 10 Gutenberg editor for core and custom Gutenberg blocks.

I tried adding glightbox via contrib module and installing glightbox manually via my custom Gutenberg blocks library. No ALT text for images that have ALT text.

Back to needs review.

Also discovered that SPACE and ENTER keys do work in Safari when tab navigation is enabled the settings.

Sorry, should be 11.x, the main development branch.

In Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks

In Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks

In Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks

In Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks

In Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks

Just added tests involving the ENTER key, as specified by the proposed resolution.

NW until pipeline passes.