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.
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">
I was just chatting with @rkoller about how nice it would be to actually know how people are using the admin breadcrumbs. Would be so useful to know if folks are going to our help.
If there is a way to enable this so that we can learn more about how authors and admins use their sites it would be so valuable. So often we just have to make assertions based on what we think would be useful to these users. Sadly, extrapolations from developers is rarely as good as watching those trying to use their Drupal site.
mgifford → created an issue.
It would be great to get a list of the URLs that are presently being covered by axe. There are some issues sneaking into Core that should have been caught by automated testing.
As with any good CI/CD process, it is important to monitor that list of URLs on a regular basis to ensure that we are using the best sampling that we can.
Phase 1 & 2 in the description identified some key URLs. It is unclear (without digging into the code) which URLs are being tested.
This makes sense to me. Why wouldn't we include this as a part of the Core Accessibility Gate?
I just ran that PNG through https://tinypng.com/ and was able to reduce its size from 15kb to 6kb..
Can we make sure that when we are creating images which will be distributed widely across different sites, that we take a moment to compress them?
Thanks @catch
I do like the idea of not running this on the weekend, but then again, not everyone shares the same idea for a weekend. I don't know enough abut the GitLab interaction to know if there's a way to check for commits.
Maybe there would be folks from GitLab who might have ideas on their side about how to reduce their server usage.
Does seem to be the kind of thing that should be part of a good aproach to ESG. https://about.gitlab.com/environmental-social-governance/
I definitely prefer the show/hide feature to be outside the input field. That example with the Light/Dark mode that you pointed to in the Youtube video would work well. Would allow us to have the button as a button too. Probably we'd want to swap the text or image to let folks know that their password is now visible (or invisible).
Also worth considering https://adamsilver.io/blog/how-to-highlight-required-and-optional-form-f...
Even adding an HR would help.
Here's a useful guide to best practices as of 2023 - https://adrianroselli.com/2023/10/splitting-within-selects.html
Would love to see this get in.
Thanks for catching that @rkoller. Really appreciate you looking over this in the UX channel and providing the feedback here.
I'd missed that name field was a required field. Are there any instances where this wouldn't be the case?
Wanted to flag this the accessibility concerns about properly labelling it:
In most cases you should provide an accessible label when using
<progress>. While you can use the standard ARIA labelling attributes aria-labelledby or aria-label as you would for any element with role="progressbar", when using<progress>you can alternatively use the<label>element.
I would say that using <label> is better.
<label>
Uploading Document: <progress value="70" max="100">70 %</progress>
</label>More good examples here - https://scottaohara.github.io/a11y_styled_form_controls/src/progress-bar/
smustgrave → credited mgifford → .
This looks great. Look forward to seeing this bug fixed.
This looks good to me. We're just re-implementing existing/tested patterns. Happy to see this in Core.
I can confirm in the /admin/structure/taxonomy
That the focus state is not announced to the screen reader user.
Here's a simple recording with VoiceOver.
I haven't tested with a screen reader yet @camilledavis, but definitely agree that the behavior in losing focus is a problem. It is a relatively small area. Folks shouldn't have to keep it over that small spot to continue reading the menu.
I attached a movie of the experience.
BramDriesen → credited mgifford → .
BramDriesen → credited mgifford → .
BramDriesen → credited mgifford → .
Thanks for starting this thread @rkoller and documenting it so well.
Would be great to be able to move to using the dialog element.
mgifford → created an issue.
Thanks @GreenSkunk I do think that this could be quite useful to show to authors. There are these PHP based tools like https://github.com/DaveChild/Text-Statistics which the Content Readability module uses but also worth noting that this could be delivered through JS too.
https://github.com/yichiang/plain-language-checker
https://github.com/duereg/too-wordy
https://github.com/retextjs/retext-readability
https://github.com/clearnote01/readability
https://github.com/btford/passive-voice/tree/master
One challenge for Drupal with this is that most of these are really focused on English specifically or at least European languages.
@quietone I moved this back to Drupal core as it really should be something we look at for CKEditor 5. Really don't see any interest in developing anything new on CKEditor 4.
mgifford → created an issue.
Ok, this is still an issue.
I can confirm that this definitely requires aria-live to alert users about the change on the UI.
So is this an upstream issue Wim? It might pose bigger problems if CKEditor is available to non-trusted users.
Hmm.. Looks like I might be responsible for this as it looks like I rolled the last patch on that issue. Not sure quite how, but..
So is this also a problem upstream? Looks like it to me: