It appears that I never filed this with with joyride. I have now filed this as Respect prefers-reduced-motion #241
Actually, this issue is probably obsolete. If Tours were to respect prefers-reduced-motion, then there would be no need for a separate setting.
Charles Belov → created an issue.
I filed this as a result of a real-life issue. Another staff member asked me to check why a particular redirect didn't seem to be having any effect. It turned out when they copied and pasted the path, they accidentally copied some additional text after the end of the path, causing the path not to match. It wasn't obvious because the full path ran past the end of the field.
Charles Belov → created an issue.
Charles Belov → created an issue.
I believe that the menu navigation as described in 📌 Ensure keyboard navigation works with the drawer Active is not behaving as described. The issue is marked as fixed. Would you prefer that I open a new issue or reopen 📌 Ensure keyboard navigation works with the drawer Active ?
Specifically, I can only navigate through the menu using tab and enter keys; the arrow keys don't accomplish anything. I actually prefer that. However, concerningly, escape does not work to exit sub-menus and I have to tab out of them. (I'm not filing this here in the current issue - I just wanted it here so that when you respond I can simply follow the desired instructions and not have to hunt this down somewhere else.)
Please advise.
Charles Belov → created an issue.
I would be concerned about a setting which disables keyboard accessibitily for all users. I would expect disabling keyboard accessibility to be a user setting, not a sitewide setting.
I'd also like to see what that top bar might look like in the context of viewing the published version (if one exists) or viewing the current draft. I'm not a big fan of hiding things under "more options"; can that be an individual user's preference setting? Some users probably prefer less clutter, others like me prefer my options to be in sight.
I have filed 📌 Ensure Local task functionality provided by Admin toolbar extra can be implemented in Navigation Active .
Charles Belov → created an issue.
Trying with a backslash immediately before the left bracket:
\
🐛
Navigation module gets error when added on simplytest.me
Active
Hoped-for result: That it prevents the expansion (not that I would expect to need to do this; my expected result without the backslash stands)
Actual result: No effect
And here I am repeating those steps as a comment:
🐛
Navigation module gets error when added on simplytest.me
Active
Charles Belov → created an issue.
Reapplying this comment to the current issue (which it does not apply to) to verify reproducibility and confirming that it happens here as well following the steps listed above in the current issue description:
Okay, I don't want to mess up your Tugboat instance. The instance on 🐛 navigation_theme() loads 'extension.list.module' for no purpose. Needs review doesn't seem to have Admin Toolbar.
However, the specific configuration I want to test is as follows:
- On /admin/modules, in addition to the Admin Tool bar, enable Admin Toolbar Extra Tools
- Click Install
- Expand Admin Toolbar Extra Tools
- Click Configure
- Check Enable/Disable local tasks display
- Click Save configuration
- Navigate to some existing content
Expected result: there is a local task menu, with the following sub-items:
- View
- Edit
- Delete
- Revisions
Presumably with Navigation also installed, the local task menu would be incorporated into the left side bar navigation.
If Admin Tool Bar isn't compatible with navigation, then I would expect there to be some other means by which I could incorporate such a menu and sub-menu into the navigation menu.
As a sidenote, I dislike the "local task" label as being jargon, and have separately filed 🐛 "Local tasks" is hard to understand Active
Charles Belov → created an issue.
Okay, I don't want to mess up your Tugboat instance. The instance on 🐛 navigation_theme() loads 'extension.list.module' for no purpose. Needs review doesn't seem to have Admin Toolbar.
However, the specific configuration I want to test is as follows:
- On /admin/modules, in addition to the Admin Tool bar, enable Admin Toolbar Extra Tools
- Click Install
- Expand Admin Toolbar Extra Tools
- Click Configure
- Check Enable/Disable local tasks display
- Click Save configuration
- Navigate to some existing content
Expected result: there is a local task menu, with the following sub-items:
- View
- Edit
- Delete
- Revisions
Presumably with Navigation also installed, the local task menu would be incorporated into the left side bar navigation.
If Admin Tool Bar isn't compatible with navigation, then I would expect there to be some other means by which I could incorporate such a menu and sub-menu into the navigation menu.
As a sidenote, I dislike the "local task" label as being jargon, and have separately filed 🐛 "Local tasks" is hard to understand Active
That's unfortunate. I wanted to check whether there were any conflicts between the Navigation and Admin Toolbar modules.
Charles Belov → created an issue.
Needs section on prefers-reduced-motion.
Note that use of the word "reduced" is an artifact that Apple got there first with their "Reduce Motion" setting in macOS and iOS. Windows uses "Animation effects" while Android uses "Remove animations," both of which imply all or nothing.
Sorry, accidentally po
Not sure whether this is a separate issue, but I'm getting the same errors today for:
Drupal core (10.2.5)
and
Additional project name:
Navigation 1.x-dev
I was on someone else's Tugboat site which had Navigation installed, so evidently there is a way to create it, but simply adding Navigation 1.x-dev, which I chose from the autocomplete drop-down, does not seem to be it.
The Tugboat environment in the current issue description is no longer available as of 4:49 pm PDT (+7) April 8, 2024.
Noting that the filename coming from an iPhone is typically just IMG followed by a sequence number, something that is not accessible. I also see many image file names on our website that are gibberish.
Has an accessibility review been done on this issue?
Charles Belov → created an issue.
Charles Belov → created an issue.
Charles Belov → created an issue.
Charles Belov → created an issue.
What is the best practice for a long-closed-as-fixed issue which has regressed/re-appeared? Comment on that issue? Or file a new issue and reference the closed issue?
I can't reopen the issue because only the maintainer can do that.
This issue appears to have regressed. As of Feb. 28, 2024:
Steps to reproduce
1. Go to https://simplytest.me
2. In the field, type "Core" (without the quotes)
3. Choose Drupal core
4. Click the add project button
5. In the project field, type "Paragraphs"
6. Choose Paragraphs
7. Click the button to create the site
8. Once the site has been created, log in as admin
9. In the admin menu, choose Manage, then Structure, then Paragraphs types
10. Click Add paragraph type
11. Type label "Single contact"
12. Click Save and manage fields
13. Click Create a new field
14. Type label "Contact name"
15. Choose text
16. Click Continue
17. Change Allowed number of values to unlimited
18. Click Save settings
19. Choose Structure, then Content types, then, on the row for Basic page, choose Manage fields
20. Click Create a new field
21. Type label "Contact information"
22. Choose Paragraphs
23. Click Continue
24. Under paragraph types, check Single contact
25. Click Save settings
26. In the admin menu, choose Manage, then Content, then Add content, then Basic page
Expected result: Contact information has no vertical three dots icon
Actual result: Contact information has a vertical three dots icon. Clicking the three dot icon reveals the menu item Drag & Drop
Charles Belov → created an issue.
Would the postponement correctly be removed at this point? It looks like the issue that this item is waiting on was resolved in 2019.
Charles Belov → created an issue.
For clarification, the research requested was done in #17 and #21.
\core\modules\ckeditor5\js\ckeditor5_plugins\drupalImage\src\imagealternativetext\ui\imagealternativetextformview.js
shows the line
labeledInput.label = Drupal.t('Text alternative');
was last committed with
c6d7b83fa35 (bnjmnm 2022-03-31 08:18:19 -0400 254)
However, if I search for c6d7b83fa35 on either drupal.org or git.drupalcode.org, I get no results.
I do see relevant issues involving @bnjmnm which were updated around that time:
- [drupalImage] Make image alt text required or strongly encouraged →
- [drupalMedia] Show the Image Media's default alt text that is being overridden →
The latter issue does have the comment:
Is "Default alternative text" the right term? Does it convey enough information?
I think that something like "Alternative text from Media Library" might be clearer?
but I don't see anything in the issue discussing "Alternative text" versus "Text alternative".
I'm actually QA, not a developer, and setting up an environment to run git blame against Drupal core is beyond my knowledge.
Minor word omission fix
@wim-leers I did a search in DuckDuckGo and Google for pages on URLs beginning www.drupal.org/project/drupal/issues which contained both "text alternative" and "alternative text" (with quotes) as character strings. None of the issues which turned up as obvious choices had a discussion about which was the appropriate choice for the label.
I also searched for git.drupalcode.org content containing "text alternative," with no results in either engine.
I have updated the issue descriptions to add my reasoning as to why I believe "Alternative text" is the correct label.
Charles Belov → created an issue.
Charles Belov → created an issue.
Charles Belov → created an issue.
Charles Belov → created an issue.
Charles Belov → created an issue.
Charles Belov → created an issue.
Charles Belov → created an issue.
Adding accessibility and needs accessibility review tags. In my experience, file names are typically not appropriate as alt text.
For maximum usability, I would suggest the following.
- Show the existing media library default alternative text outside the field, so that someone who is typing new text in the field can refer to the existing text while they are typing the new text. This reduces cognitive load and also makes it easier for the content editor to
- decide whether they want to keep the default alt text or write new alt text.
- revert any edits while still having the original available to them.
- Ensure that the displayed existing text is copy-and-paste-able.
It appears from the demonstration animated gif of the decorative image toggle → that the default is decorative. The default would best be non-decorative, requiring that the editor assertively choose that the image is decorative.
Please clarify as to whether this animation shows the default or reflects an image that was previously set to decorative.
Confirmed working as requested in Drupal 10.2.2. Closing as unable to reproduce.
Charles Belov → created an issue.