mgifford → created an issue.
Thanks @rkoller. Installation is critical to adoption.
mgifford → created an issue.
Was specifically from https://docs.pantheon.io/supported-drupal#drupal-cms-on-pantheon
Drupal CMS is currently available to install via this Dashboard Link or Terminus:
Worth noting that I just got this error on Pantheon by following https://docs.pantheon.io/release-notes/2025/01/drupal-cms-upstream
And installing a new site.
adding link to Mobile documentation or responsive images.
Adding this issue here https://www.drupal.org/project/gin/issues/3500065 🐛 Invalid ARIA attributes Active
mgifford → created an issue.
mgifford → created an issue.
Having a report like this that is able to centralize bad accessibility is useful. You'll be able to sort by date which is useful. There may be other ways to organize the information as well in that table.
I would love to see these errors show up on the admin pages where the images are used too.
Great catch @rkoller. We do need to improve the user interface to see it meets the Minimum Target Size requirements.
https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum
Added in WCAG 2.2, this isn't yet a requirement by many countries (but it will be soon).
https://tetralogical.com/blog/2023/10/05/whats-new-wcag-2.2/
There are some bookmarklets to help with this too, this one by Steve Faulkner - https://github.com/stevefaulkner/targetsize/blob/main/bookmarklet.md
This is important for our community. As Drupal CMS becomes a reality, we need to ensure it is accessible.
I'd love to see this brought into Core. This adds some missing semantics to our work.
This makes sense to me.
Took a look at the code and it seemed reasonable. @smustgrave thanks for doing the manual testing. Would be nice to get it in.
@rkoller pointed me to both Craft CMS & Plone. Here are some other CMS that Starshot (Drupal CMS) has identified as key competitors (except Plone):
Craft
https://craftcms.com/accessibility/report
WordPress
https://vpats.wordpress.com/wp-content/uploads/2017/10/geoscience-world.pdf
Webflow
https://uploads-ssl.webflow.com/6140f4a34b5bb2103667d3ec/6144f1b8b581660...
Shopify
https://www.shopify.com/ca/accessibility/vpat-checkout
Plone
https://plone.org/accessibility/plone-5-2-vpat.pdf/@@download/file
Removing CKEditor Accessibility Auditor as it only works with D7 and CKEditor 4. This should be reconsidered if it is upgraded. Until then, use Editoria11y.
swirt → credited mgifford → .
swirt → credited mgifford → .
Looks like it almost runs on SimplyTest.me, but would be good if it did.
Are there any pre-installation things that need to be done?
Can we get someone to re-roll this patch?
Thanks @rkoller this is great. I'd like to see this patch include Ralf's suggestion to collapse the first drop button as soon as another drop button is expanded. We don't want to introduce an accessibility issue for keyboard only users, by fixing an issue for screen reader users.
I would say that from Ralf's demo that the patch would currently violate SC 2.4.11: Focus Not Obscured (Minimum) (Level AA).
Let's open up a follow-up item about the drop button label, as suggested by Ralf.
ckrina → credited mgifford → .
Just tagging it here.
Thanks for raising this at today's Drupal A11y Office Hour Simo!
I think that the JavaScript could likely be done with something like https://stackoverflow.com/questions/1655769/fastest-md5-implementation-i... but there are probably better ways to do this.
It is also interesting to think about the CO2 costs of loading extra JS and weight that against the occasions where someone uploads a file. I don't know how to balance that score out, but it is something to think about.
Much easier to think about adding a library to do the md5 hash on the backend I assume. It would only be executed when needed.
Sorry, I don't know that this should be tagged with sustainability given that this is a bug in an edge case. Should be fixed, but I'm changing my mind.
WebP look ready to roll though:
https://caniuse.com/?search=webp
I don't see this getting into D7, can we get it in d10 or 11?
AVIF & WebP look ready to roll though:
https://caniuse.com/?search=avif
https://caniuse.com/?search=webp
I don't know why we're trying to add this to D7 at this point. Bumping it up to D10. Hopefully we don't have to wait till 11.
AVIF & WebP are already ready to roll:
https://caniuse.com/?search=avif
https://caniuse.com/?search=webp
Doesn't seem to be a lot of support for JPEG XL https://caniuse.com/?search=JPEG%20XL
AVIF & WebP look ready to roll though:
https://caniuse.com/?search=avif
https://caniuse.com/?search=webp
Also, we can build on the work of another CMS that's already moved this way:
https://wagtail.org/blog/wagtail-greener-and-leaner/
How often are we running these tests? Seems like a good investment of time to cut the execution time in half, even if it's a matter of allowing us to know earlier that the patch works.
Great to see this.
This is how Wagtail is currently doing this:
https://wagtail.org/sustainability/
https://wagtail.org/blog/wagtail-greener-and-leaner/
Also an idea for relative CO2 impacts (all estimates of course):
https://sustainablescreen.org/unlocking-sustainable-speed-optimising-ima...
mgifford → created an issue.
AVIF and WebP look pretty well supported now.
https://caniuse.com/?search=avif
https://caniuse.com/?search=webp
Nice. Any sense of how many bytes or even kb's might be saved by doing this? Given the number of Drupal installs in the wild, this seems like it could reduce a lot of CO2 distributed across our community.
I would like to have some nightwatch-axe Core tests set up to test the new navigation. I think that the dynamic functionality that we're going to want to be able to deliver should come with some dynamic automated tests.
I'm just looking at the source here.
// Because CKEditor5 re-renders aria-label every time on focus/blur,
// overwrite the label to appropriate field label value.This sounds like an upstream bug. Shouldn't CKEditor just do this:
// Update aria-label with the value from default textarea label.
Not that we can't too, but surely, if there is a label in the text area, CKEditor should respect that, right? Or am I missing something?
Interesting.. I hadn't heard of AccessibilityHelp before this:
https://ckeditor.com/docs/ckeditor5/latest/api/module_ui_editorui_access...
Documentation for authors is definitely important:
https://accessibilitycluster.com/main-results/documentation
But this seems to be about help for authors who need to learn the keystrokes that are needed to use CKEditor.
Keep in mind that there are inherent problems with Keyboard Shortcuts https://webaim.org/techniques/keyboard/accesskey
Worth comparing with https://dequeuniversity.com/library/aria/progress-bar-bounded
Many uses of progress bars are essentially static, but Drupal we often use them as dynamic elements which should be updated with aria-live.
Deque uses:
<div id="progressbar-bounded" class="deque-progressbar deque-progressbar-bounded">
<progress role="progressbar"
aria-valuemin="0"
aria-valuemax="100"
aria-label="A bounded progress bar from 0 to 100">
</progress>
<p>
<button class="deque-button" id="start-progressbar">
Start
</button>
</p>
</div>They leverage the ARIA progressbar role. I"m not certain that this is needed, but wanted to note it here.
MDN just states:
If the progressbar role is applied to an HTML
element, the accessible name can come from the associated . Otherwise use aria-labelledby if a visible label is present or aria-label if a visible label is not present.
What is in the latest patch I think is:
<div id="${id}" class="progress" aria-live="polite">
<label>
<div class="progress__label"> </div>
<progress class="progress__element" value="0" max="100"></progress>
</label>
<div class="progress__percentage"></div>
<div class="progress__description"> </div>
</div>I'm not sure how much the JavaScript would affect things here either. I haven't compared the two.
How is what we implemented different than what you can see in their demo https://ckeditor.com/ckeditor-5/demo/feature-rich/
The contrast I see for the focus of the boarder is #3879EB / #FFF which is 4.1.2. That's good enough for SC 1.4.11 Non-Text Contrast (Level AA) if the visual presentation only needs a contrast ratio of 3:1 against adjacent color(s).
I didn't see a corresponding problem in their issue queue https://github.com/ckeditor/ckeditor5/issues
but the bigger issue is that i couldn't replicate this in their demo.
Thanks @rkoller. Thanks for documenting this all. It would be great to help make it easier to identify what elements are active. We can make this easier for everyone to identify.
Thanks smustgrave - I appreciate you verifying that. I wasn't starting with D11 but obviously should have been here.
That makes sense @camille.davis@civicactions.com
I tested with code without that.
In which case I don't have a problem removing the redundant text.. Who wants redundant text!
I like this idea, but I'm missing something.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attribut...
I couldn't find aria-current="page" in the page.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attribut...
Here's a snapshot of what I see with SimplyTest.me & D10:
<li class="tabs__tab js-tab is-active js-active-tab" data-original-order="1">
<a href="/user/1/shortcuts" class="tabs__link js-tabs-link is-active" data-drupal-link-system-path="user/1/shortcuts">Shortcuts</a>
<button class="reset-appearance tabs__trigger" aria-label="Tabs display toggle" data-drupal-nav-tabs-trigger="">
<svg fill="none" height="16" viewBox="0 0 16 16" width="16" xmlns="http://www.w3.org/2000/svg"><path clip-rule="evenodd" d="m15 9h-14c-.56016 0-1-.43984-1-1s.43984-1 1-1h14c.5602 0 1 .43984 1 1s-.4398 1-1 1zm0-5h-14c-.56016 0-1-.43984-1-1s.43984-1 1-1h14c.5602 0 1 .43984 1 1s-.4398 1-1 1zm-14 8h14c.5602 0 1 .4398 1 1s-.4398 1-1 1h-14c-.56016 0-1-.4398-1-1s.43984-1 1-1z" fill="#003ECC" fill-rule="evenodd"></path></svg> </button>
</li>I've uploaded some screenshots with/without the patch.
I'd love to know what I am missing.
We should definitely fix this. After listening to this page with a screen reader it clearly needs work. I think it was working better when we first introduced this in Drupal 7, but time erodes all things.
There's been some discussion in Slack to move the password strength indicator before the input form so that a user is told how they should comply before fill in the form. I thought that the password strength indicator was semantically linked to the password field by aria-describedby but can't seem to find that now.
I suspect with these changes we should put on "Needs Accessibility Review" and "Needs Usability Review" but I wonder if we can't commit this and create two smaller follow-up issues.
This one is already approaching its 10th anniversary.
I took a look with this issue with VoiceOver, and with keyboard-only reviews. This looks good. Like the new pattern with the show/hide text.
I don't know how to do this. There are two times.
Thanks for posting this @rkoller. It is clear you've put a lot of work into this and giving it a lot of careful consideration. I wanted to emphasize that not all accessibility errors are covered by WCAG SC. Cognitive is going to be covered much better in WCAG 3.0 but it is likely years away before this becomes a W3C Recommendation. That doesn't mean we can wait to address these issues.
I do think that it would be great to do more usability studies with our authors and admin. Would be interesting to do A/B testing with different ways of organizing and separating the content.
This also may be a space to explore the use of prefers-contrast to allow more individual choice.
It would be interesting to see if there are ways that design folks could address some of these concerns in ways that me (as a non-designer) can't necessarily anticipate.
Just adding a reference for this:
https://web.dev/articles/control-focus-with-tabindex#remove_an_element_f...
It is easy enough to test for everyone with a keyboard.
Identifying two different times for the monthly meetings.
mgifford → created an issue.
My only concern with this change to:
background: #004eff;
background: var(--color-blue-500);
is that I'd like to know what the ratios are to the foreground color.
#004eff has lots of room with a foreground of #fff
https://www.whocanuse.com/?bg=004eff&fg=ffffff&fs=16&fw=
I need to know what the values would be for var(--color-blue-500).
Knowing this I think we can remove the Needs accessibility review tag.
Thanks for adding that @shaal.
I do think that there must be a reasonable solution to work for from that mix of links. Doesn't need to be perfect, but should be able to do up/down as well as left/right so that we can change order and hierarchy.
Just taking myself off of this list as I keep having conflicts or not being able to make it. I may re-join in the future.
mgifford → created an issue.
@swirt, I like your YAML style direction, but it is different than what is proposed here:
https://humanstxt.org/Standard.html
Maybe something like this:
/* Drupal Core Maintainers */
See core/MAINTAINERS.txt
/* Site - see https://humanstxt.org - for format suggestions */
/* Please add site specific contributions below */
/* TEAM */
Your title: Your name.
Site: email, link to a contact form, etc.
Social Media: whatever you use
Location: City, Country.
/* THANKS */
Name: name or url
/* SITE */
Last update: YYYY/MM/DD
Standards: HTML5, CSS3,..
Components: Modernizr, jQuery, etc.This makes sense to me. It's a simple change, but one that I think can avoid some confusion for users expecting a link.
Think Windows High Contrast Mode (WHCM) is being used as "high contrast" more consistently.
Adding reference to Windows High Contrast Mode.
Adding reference to Windows High Contrast Mode.
Adding reference to Windows High Contrast Mode.
Adding reference to Windows High Contrast Mode.
Adding reference to Windows High Contrast Mode.
Adding reference to Windows High Contrast Mode.
Adding reference to Windows High Contrast Mode.
Adding reference to Windows High Contrast Mode.
Adding reference to Windows High Contrast Mode.
Adding reference to Windows High Contrast Mode.
Adding reference to Windows High Contrast Mode.
Good call @andy-blum.
As far as things we could possibly support.
- Support for AAA colors
- Support for a low contrast mode (we really haven't touched on this at all, but could be useful for some users).
- Dark mode
- Defined custom colors for: foreground-color, background-color, text-decoration-color, text-emphasis-color, border-color, outline-color, column-rule-color
I don't have a lot of guidance on how to do this, which is which I've included a bunch of research links as well as opening this as a meta issue.
Crossing out inverted-colors because of lack of support https://caniuse.com/?search=inverted-colors
mgifford → created an issue.
Let's continue to build on this for now. It's a short issue.
I changed the title so that it reflects that there is now a description.
This is terrific. Thanks @dmundra
So how often should we review this list of URLs?
Probably that should be a new issue. Should we close this one?
Adding clarification about accessibility section.
Adding a link to https://nightwatchjs.org/ and some basic spelling/grammer things.
Adding new article, The Road to Accessible Drag and Drop (Part 1) https://www.tpgi.com/the-road-to-accessible-drag-and-drop-part-1/
I love the idea of making the caption visible as an option. It could definitely improve the experience by providing better context for everyone viewing it.
The <caption> element is within the <table> so it is by default associated with data the tables so I'm not tagging this as 1.3.1 SC.
@rkoller & I were talking. This advent calendar article came up You don't need JavaScript for that. Most browsers support the dialog element now.
Not that this would be a trivial shift, but it does seem like this might be a good time to consider it.
There are always dangers in overwriting the default browser behavior. It is usually more work than it is worth. Still, Eric's article is focusing on the page scroll bar and I can't find references to scroll bars within the page.
Worth looking into though.
Adding a section on screen magnification.
nicxvan → credited mgifford → .
Looking at some recent examples, including Scott's above, I'm not sure that we need any aria for the detail/summary. There was an outstanding bug for NVDA, but I think that's been resolved now.
Some follow-up links:
- https://blog.learningtoo.eu/expanding-summary-details-accessibly
- https://dequeuniversity.com/library/aria/expand-collapse-summary
- https://www.hassellinclusion.com/blog/accessible-accordions-part-2-using...
- https://developer.mozilla.org/en-US/docs/Web/HTML/Element/summary
Wouldn't it be nice if we could just get it down to very basic HTML - <summary class="claro-details__summary">