__group__ ticket summary owner component _version priority severity milestone type _status workflow _created modified _description _reporter Unpatched Enhancements 59414 XML-RPC - add updateMedia endpoint XML-RPC normal normal Future Release enhancement new 2023-09-20T19:33:26Z 2024-03-05T15:53:56Z "In #58582, @thomashorta reported on alt attributes missing from the XML RPC endpoints. Fetching that data was fixed in [56637], but adding an endpoint to update media that specifically handles media data like alt attributes requires a more substantial enhancement. From #58582: Updating MediaItems through the XML-RPC API is also done directly by the Posts API, more specifically through wp.editPost (codex), which also doesn't support an alt field. This makes sense, as this API is more generic, but at the same time, there are no specific updateMedia methods in the Media API. Suggestion for updating I'm not sure about this one, but I think a new method in the Media API would be needed (e.g.: wp.updateMediaItem) to properly manipulate a specific input struct and call the Post update functions internally." joedolson Unpatched Enhancements 30180 wp_get_attachment_image_src does not return alt or meta antpb Media normal normal Future Release enhancement assigned 2014-10-29T18:42:55Z 2023-07-21T15:37:32Z "In practical use,wp_get_attachment_image_src is very useful for displaying an attached image - but requires a separate call to get any other image meta or the alt attribute. In addition to making any application that needs alt attr or meta data for display simpler, having the alt attribute present in this function increases the likelihood that developers will use the alt attribute in their ultimate output. " joedolson Unpatched Enhancements 19867 wp_dropdown_users() still not scalable Users 3.3.1 normal normal Future Release enhancement assigned 2012-01-20T22:04:27Z 2024-03-25T02:34:10Z #14572 made huge improvements to the performance of wp_dropdown_users(), however, on certain sites that have an unusually large set of authors, wp_dropdown_users() still isn't usable. It either causes a memory error on the server, or potentially crashes the client browser due to content size. prettyboymp Unpatched Bugs 50703 WordPress classic editor accessibility issues for insert/edit links list joedolson* Editor 5.4.2 normal normal Future Release defect (bug) accepted 2020-07-20T13:02:44Z 2021-06-24T19:16:09Z "We are facing some keyboard accessibility issues with Insert/edit link list from the editor. We are not able to access the items from the list using up arrow, down arrow, enter and space keys. Please find the below image for reference. [[Image(http://meedev.westus.cloudapp.azure.com/dev-old/Wp_editor_issue.png)]]" fornandakishore Unpatched Bugs 58828 Whenever bulk updates are done in wp-admin/update-core.php, no feedback is given, until all updates are done williampatton Upgrade/Install 6.2.2 normal normal Future Release defect (bug) assigned 2023-07-18T05:46:45Z 2024-03-13T04:31:21Z "This bug exists since I know WP, and it still persists on the latest version. 1. Go to wp-admin/update-core.php 2. Check all boxes for pending updates 3. Click update - The page reloads. - Nothing happens. The page just stays grey (admin bar etc are there, but the page itself is empty) - After a while, which can be a very long while if a lot of updates are pending, the screen gets populated (without page reload) with log like {{{#!php The update process is starting. This process may take a while on some hosts, so please be patient. Enabling Maintenance mode… Updating Plugin {Plugin name} (1/12) {Plugin name} updated successfully. Show details. Updating Plugin {Plugin name} [etc] All updates have been completed. Go to Plugins page | Go to WordPress Updates page }}} This log clearly should happen _while_ it is updating, and not once it is done. There is no spinner, no feedback, nothing that tells the user ""something is working"" " bedas Unpatched Bugs 39044 W3C Validator warning: Article lacks heading. Consider using h2-h6 elements to add identifying headings to all articles General 4.6.1 normal normal Future Release defect (bug) new 2016-12-04T13:06:09Z 2020-04-30T05:26:29Z "File: wp-includes/class-walker-comment.php Screenshot incoming." henry.wright Unpatched Bugs 35937 "Visual improvements for the comment ""pending status""" Comments normal normal Future Release defect (bug) new 2016-02-24T16:25:05Z 2019-01-13T16:55:31Z "Splitting this out from #35392. While working on #35392, noticed and agreed there's room for some visual (and further accessibility) improvements. Specifically, the comment ""pending status"" relies on a small ""flag"" icon, followed by a `[Pending]` text. From a design perspective, this could use some love. Whether it would be some additional, descriptive, text or a new icon etc. it would be possible to expand the new text or icon with some `screen-reader-text` in order to provide a reasonably understandable feedback for assistive technologies users. Worth noting this applies to the Dashboard ""Recent Comments"" widget and the list of comments in the Comments screen and Edit post screen as well, where the pending status information is conveyed using just color. cc @melchoyce [[Image(https://cldup.com/IWyv7rKuEE.png)]] " afercia Tickets Needing Feedback 23562 Using Speech Recognition Software with the Add Media Panel joedolson* Media 3.5.1 normal normal Future Release defect (bug) accepted reporter-feedback 2013-02-20T16:06:02Z 2023-08-24T13:36:57Z "Linked to #23560 this ticket specifically concerns the speech recognition user's accessibility experience of the Add Media functionality. I'm using Dragon Naturally Speaking with IE9 on Windows 7 - a typical setup as Dragon works best with IE. Within the Edit Post screen I can use Dragon to action the Add Media link successfully. The command in Dragon for such an action is ""Click Add Media"". This works, but then I run into the following problem: * With the exception of Set Featured Image, none of the other links on the panel appear to be directly accessible with Dragon. * If I select Set Featured Image I can't action any of the other links. Dragon users can use voice commands to replicate pressing the tab key. The experience then mirrors that outlined in #23560 - but of course this cannot be used to select the images or other files. It is possible for Dragon users to interact with screens using mouse commands but it is an incredibly laborious and time consuming process - used only as a last resort. If one of the images is selected, the information panel for that images opens to the right. Unfortunately none of the input fields (for title, alt, etc) are directly available to Dragon. Ironically, the Insert Into Post button can be accessed directly with a voice command. Some investigation needs to be done as to why most of the links and input fields cannot be directly accessed by Dragon when the panel is opened. This is a parallel with the situation on the Theme Customizer panel. It is interesting that the Set Featured Image link and the Insert Into Post button '''can''' be directly accessed. What is different about them? " grahamarmfield Unpatched Bugs 50202 Use tag instead of tag in `Walker_Comment::html5_comment` Comments normal normal Future Release defect (bug) new 2020-05-18T14:32:56Z 2020-08-26T13:48:40Z It is well documented that when some text is bolded using the tag, it will come to no benefit for users using screen readers. This patch aims to fix that in an instance of `html5_comment` method in `Walker_Comment`. itowhid06 Unpatched Enhancements 54265 Updates UI: offer multiple variations of available updates nags to highlight older updates audrasjb Upgrade/Install normal normal Future Release enhancement reopened 2021-10-14T15:39:10Z 2024-03-05T15:41:44Z "Today, when an update is available for one of your plugins, for Core, or for a theme, the update notice is always the same: - It uses a single and consistent color across the different wp-admin screens. - The update messager remains the same until you've update the plugin/theme/core. While that works, I wonder if there could be an opportunity to better emphasize the need to update things on your site. Google Chrome comes to mind: its update warning is first green, then turns yellow and then red to highlight the need to update. I wonder if WordPress could do something similar: - If an update has been available for less than a month, have the notice displayed the way we display it today. - If that update has been available for 2 to 3 months, have the notice turn more yellow / be more of a warning. - If that update has been available for more than 3 months, have the notice turn red. We may even want to be more granular there; core security releases would be red right away for example. Somewhat related: #33374" jeherve Tickets with Patches 51284 Update style for side meta boxes azhiyadev Editor 5.5.1 normal normal Future Release enhancement assigned has-patch 2020-09-10T02:56:22Z 2021-12-19T07:29:07Z "In the latest version 5.5.1, WordPress adds the arrows to the meta box handles to allows users to move a meta box up or down. That works nicely for meta boxes below the content area. However, for the side boxes, the arrows takes a lot of space and reduce the space for the meta box title. The 2nd problem is that the toggle icon (collapse/expand) is different from the Gutenberg panel icon. I attach a screenshot to see the problems clearer. " rilwis Tickets with Patches 56320 Update mediaelement.js to the latest version External Libraries normal normal Future Release defect (bug) new has-patch 2022-08-01T18:20:19Z 2022-08-26T08:44:23Z "Follow up to #56319 (updating to the latest 4.x release). The latest version of `mediaelement`, as of today, is [https://github.com/mediaelement/mediaelement/releases/tag/5.0.5 5.0.5]. Version 5.0 made the player WCAG 2.1 compliant, but some of the changes required are breaking. It's possible this update can be merged into WordPress without issue, but this update needs to be fully tested, and there may be a developer note required to communicate action that needs to be taken by plugin and theme developers." desrosj Unpatched Bugs 36973 Update FTP credentials form design Upgrade/Install normal normal Future Release defect (bug) new 2016-05-30T09:27:42Z 2018-03-12T16:16:03Z "As reported by @melchoyce in https://github.com/obenland/shiny-updates/issues/100, the filesystem credentials dialog needs some love to improve accessibility and the overall design. Here's how it could look like: https://cloudup.com/cnvj5NqMefR Her notes: 1. Update modal style to bring more in-line with other wp-admin modals — like including an ""x"" for closing (even though there's also a cancel button) 2. Make ""Proceed"" primary 3. Also consider changing ""proceed"" to something more descriptive — maybe connect? Proceed might be okay, it's just such a weird-sounding word. Maybe switch the ""proceed"" in both the description and the button to ""continue."" 4. ""This password will not be..."" could stand to be decreased in size just a little and made a lighter grey, to match descriptions on the settings pages. At the very least, the line-height should decrease. 5. ""Authentication Keys"" is at the same level of hierarchy as the field labels. It should probably be bigger, since it's a header above the labels. 6. Additionally: the modal is really tall for mockup purposes, but would ideally be whatever height we normally max modals out at. Any content not visible because of height would be scrollable in the modal, like we do in others. See also: #34376" swissspidy Unpatched Enhancements 31818 Uniform Search Form Display/Experience joedolson* Administration 4.2 normal normal Future Release enhancement accepted 2015-03-31T11:05:37Z 2023-04-28T15:20:54Z "In our recent testing of the search functionality we've found that there are currently five different search types across the admin. A full description of what the tests entailed, their results, and a link to the Slack discussion can be found here: https://make.wordpress.org/accessibility/2015/03/30/usertest-the-search-functions-in-the-admin/ To summarise, these are the five that we've found: * Search input without submit button, no live search (need to press Enter) * e.g. Media Library list mode * Search input without submit button, live search fires “as you type” * e.g. Media Library grid mode, Themes (add new, wp.org API), Network Themes (add new, wp.org API) * Search input no submit button, live search fires “as you type” (more a “filter current collection” than a search) * e.g. Themes (installed themes), Customizer add widget, Plugins (installed plugins) * Search input with hidden submit button, press Enter or tab and submit the hidden button (after the search, the “typeselector” select appears) * e.g. Plugins (add new), Network Plugins (add new) * “Classic” search: search input with submit button, press Enter or submit button * e.g. Posts, Categories, Tags, Pages, Comments, Users, Network index: search users, Network index: search sites, Network Sites, Network Users, Network Themes (installed), Network Plugins (installed) What we'd like to propose is to bring this down to two and ensure they work well. This could then be used as a launchpad to further unify the search experience and use a single type across the board. The lucky two would be: * the classic one, the same for every search, with visible submit button (already commonly used) * the dynamic one, with some improvements like adding wp.a11y.speak to show the results count, and making sure focus doesn’t change dynamically " Cheffheid Unpatched Bugs 47359 Unable to distinguish post formats when viewing list tables on mobile Post Formats 5.2.1 normal normal Future Release defect (bug) new 2019-05-23T01:03:32Z 2021-04-27T16:51:41Z "Post format icons were recently removed from post list tables and a post format dropdown menu introduced to allow people to filter posts by format. See #46591 and [44961]. On narrow screens, however, the filter tools are hidden leaving mobile users with no way distinguish the format of their posts. I suggest we revisit the decision to remove post format icons and consider the mobile user experience." ajfleming Unpatched Bugs 50696 UI issue in customizer menus section Customize 5.5 normal normal Future Release defect (bug) new 2020-07-19T05:42:31Z 2021-06-01T03:13:09Z "I have found 2 issues in customizer menu section 1) Input box-shadow issue if the input is invalid. 2) Add button properly not display I have attached an image for better understanding." dilipbheda Tickets Needing Feedback 54412 Twenty Twenty: Letters move when opening accordion menu Bundled Theme 5.8.1 normal normal Future Release defect (bug) new reporter-feedback 2021-11-10T10:25:53Z 2023-04-28T15:53:28Z "I haven't changed anything, this is the original version of Twenty Twenty. This happens in any browser of the latest version, I have Windows 10. Gif - \\https://gifyu.com/image/ePvd screen - \\https://ibb.co/tX7XjTJ " mike77777 Unpatched Enhancements 54852 Twenty Twenty: Consider less aggressive motion preference styles Bundled Theme normal normal Future Release enhancement new 2022-01-18T19:07:15Z 2022-01-19T06:14:30Z "Twenty Twenty styles create animations and transitions but then disable all that animation for people who set the reduced motion preference in their browser/OS. {{{ @media ( prefers-reduced-motion: reduce ) { * { animation-duration: 0s !important; transition-duration: 0s !important; } } }}} The theme needs to continue honoring the preference, but it could define each of its animations within a `(prefers-reduced-motion: no-preference)` media query—and remove the `0s !important` styles—instead. That way, the theme would be responsible for its own motion without disabling motion from other stylesheets (from plugins). Related: #54174 (Twenty Twenty-One)" sabernhardt Tickets with Patches 56496 Twenty Twenty-Two: Update comment block markup Bundled Theme normal normal Future Release defect (bug) new dev-feedback 2022-09-02T09:37:52Z 2024-01-19T11:13:34Z "The comment block markup in Twenty Twenty-Two is using an outdated version of the block: `` In the Site Editor, the block shows the following notice: You're currently using this block in legacy mode. This should be updated to use the latest version of the comments block, e.g. wrapped in the `` tag." mikachan Slated for Next Release 60335 Twenty Twenty-Four: FAQ Pattern creates accessibility issues Bundled Theme 6.4 normal normal 6.6 defect (bug) new has-patch 2024-01-24T09:04:02Z 2024-03-05T15:28:33Z "This was reported by @alh0319 in https://github.com/WordPress/twentytwentyfour/issues/743 I have copied and pasted the text from the issue, as well as the comment. ---- The FAQ Pattern packaged in the theme uses multiple Details blocks in a row. While it's not labeled or promoted as an accordion, this functionally behaves like an accordion, and most users, especially non-tech-savvy ones, will see this pattern as an accordion and use it as such throughout their site. They are likely to create long lists of FAQs in this manner when given the pattern as an example. Core themes should set website owners up for success and provide a good example of how to build websites that are accessible. This pattern does neither. Accessible accordions have headings, which are vital for navigation with a screen reader. Lists of FAQs, which frequently include important information about products, services, and companies, need headings so that screen reader users can access that information easily. The details block is not a substitute for an accordion block and users should not be encouraged to use it as one. This pattern should be removed from Twenty Twenty-Four. Either the pattern should be removed completely, or the questions and answers that are built with the details block should be rebuilt with the questions as H3s and the answers as visible paragraphs. If an accordion block can be built quickly, it could be replaced with that, but given testing time needed, it would be better to remove this pattern from the theme ASAP to reduce the number of websites and that using it and will need to be fixed later. == Step-by-step reproduction instructions Insert FAQ pattern into a page and inspect it. == Expected behavior Accordions should be built accessibly. Here's a good [example of how the accordion block should be coded for accessibility https://designsystem.digital.gov/components/accordion/]. We shouldn't create patterns that add accessibility problems to user's websites. == Additional context Please reference the discussion on the [https://github.com/WordPress/gutenberg/issues/21584 New block: Accordion block issue] in the Gutenberg repo for more information on why the Details block should not be used as an accordion. @joedolson said in that discussion that he didn't think it was an issue, so he may want to way in here, but I disagree. ----- Comment by @alexstine Not trying to tell anyone told you so but I felt like this could be one of those blocks that would be misused. Upvote to doing something about it. " poena Slated for Next Release 60808 Twenty Twenty-Four: Black outline around the Navigation block submenu-expanding button Bundled Theme trunk normal normal 6.5.1 defect (bug) new dev-feedback 2024-03-20T03:01:53Z 2024-03-28T07:05:58Z "This appears to be a regression introduced in https://core.trac.wordpress.org/changeset/57739 Brought over from the Gutenberg repo: https://github.com/WordPress/gutenberg/issues/59944 ---- == Description When a sub-menu item is present, when clicking on the sub-menu item or on the parent menu item, a black border is shown around the items. [[Image(https://cldup.com/kNOVprCJ_d.png)]] Video: https://cloudup.com/cm8LVp_p6kN == Step-by-step reproduction instructions 1. go to the site editor 2. add a navigation block 3. add an item and a sub item 4. publish changes and visit the site 5. click on the sub-menu item and on the parent item 6. see the black border == Environment info WordPress 6.5 RC2 2024 theme == Please confirm that you have searched existing issues in the repo. Yes == Please confirm that you have tested with all plugins deactivated except Gutenberg. Yes" jordesign Slated for Next Release 49950 Twenty Twenty (1.2) Horizontal menu - Submenu joedolson Bundled Theme normal normal 6.6 defect (bug) assigned has-patch 2020-04-18T16:04:32Z 2024-03-05T15:24:47Z "Hi there! I've tried adding a submenu in the horizontal menu but there is some issue regarding accessibility when I tested it. It fails the Success Criterion 1.4.13 Content on Hover or Focus of WCAG : https://www.w3.org/TR/WCAG21/#content-on-hover-or-focus The submenu cannot be dismissed. If there are many links in the submenu, keyboard navigation is tedious since the person will have to tab all of the content of the submenu before reaching the next item of the menu. Expected fix: The submenu should be dismissable with the Esc key for example. Here is a menu with a submenu that implements the SC 1.4.13 : https://www.eesc.europa.eu/ It's my first ticket, so I hope I'v done it properly. Regards, Luce" lcarevic Slated for Next Release 60496 Twenty Sixteen: visual and DOM order of elements in the footer mismatch joedolson Bundled Theme normal normal 6.6 defect (bug) assigned has-patch 2024-02-12T09:22:16Z 2024-03-14T21:29:45Z "In the footer of Twenty Sixteen, the footer site info and the social menu visual order and DOM order mismatch. For accessibility, visual order and DOM order must alwasy match when they affect 'meaning or operation'. Basically, altering the visual order via CSS properties like `order` and the various flexbox/grid `*-reverse` properties must be avoided. It is only allowed for purely decorative elements like, for example, the position of an icon within a button (there was such a case in the Gutenberg editor). Reference: WCAG 2.2 1.3.2 Meaningful Sequence (Level A) https://www.w3.org/TR/WCAG22/#meaningful-sequence 2.4.3 Focus Order (Level A) https://www.w3.org/TR/WCAG22/#focus-order Twenty Sixteen uses the `order` property to change the order of the social menu and site info on large screens. On small screens, the visual order is social menu first, site info after (matches the DOM order). Instead, on large screens the site info is first, the social menu is second. See screenshots." afercia Unpatched Enhancements 44537 Twenty Seventeen: submenu is not available from keyboard with disabled java script Bundled Theme normal minor Future Release enhancement new 2018-07-06T15:01:43Z 2019-01-18T20:59:07Z webest Unpatched Bugs 45796 Twenty Nineteen: Mobile menu needs improvement for navigating on touchscreen via keyboard Bundled Theme 5.0 normal normal Future Release defect (bug) new 2018-12-30T19:32:14Z 2020-02-24T21:03:04Z "Copied over from https://github.com/WordPress/twentynineteen/issues/723#issuecomment-450173083 (hattip @afercia): When the ""more"" menu is expanded on a touchscreen device, there are several hidden tab stops that cause issues when navigating the site via keyboard. These are: * hidden sub-menu items are still focusable * all the links in the page are still focusable When the menu is open it's still possible to tab away from the menu and navigate with the keyboard through all the focusable elements in the page. If the intent is to show a full-screen menu, the menu should behave like a modal and tabbing should be constrained within the modal." laurelfulford Unpatched Bugs 45673 Twenty Nineteen: Front page entry-title should be h1, not h2 Bundled Theme normal minor Future Release defect (bug) new 2018-12-17T11:08:42Z 2023-11-08T07:49:40Z Posts published on the front page should use h1. This is encouraged with HTML5, and prevents wrong content structure as seen here: http://take.ms/DWnFH perandre Unpatched Bugs 45904 Twenty Nineteen: .button doesn't override link color Bundled Theme 5.0 normal normal Future Release defect (bug) new 2019-01-10T16:00:41Z 2024-02-01T08:48:17Z "Originally reported by @crunnells in Twenty Nineteen's GitHub repo: I noticed this one [https://2019.wordpress.net/ the theme demo site] when I tried to change the ""Get in touch"" button into a link. If you put a link inside of an element with the `.button` class, the link color is the same color blue as the background, so the text can't be read. The same thing occurs when you try ``, so we'll need to have an override on the link color so that it's readable. Moved over from: https://github.com/WordPress/twentynineteen/issues/746" laurelfulford Unpatched Bugs 47051 Twenty Nineteen theme sub-menu returns error in WAVE accessibility tool nataliemac Bundled Theme 5.0 normal normal Future Release defect (bug) assigned 2019-04-26T16:21:38Z 2019-11-03T21:23:14Z "I'm building a site in (a child theme of) Twenty Nineteen. In the top menu, each instance of a menu item that has a child item is returning one error in the WAVE accessibility tool. The reported error is ""empty button"" and below is the explanation: What It Means A button is empty or has no value text. Why It Matters When navigating to a button, descriptive text must be presented to screen reader users to indicate the function of the button. How to Fix It Place text content within the " johnfclifford Unpatched Enhancements 24766 Title attributes galore. They serve no useful purpose. sabernhardt* Administration normal normal Future Release task (blessed) accepted 2013-07-16T00:29:25Z 2024-02-14T19:05:13Z "This is a full list of methods, including what files they're from, where HTML title attributes are in use. The title attribute provides a tooltip on certain browsers. Other than that, it is essentially useless. As provided in WordPress, the title attribute is both redundant and useless, because in most cases, it is a complete duplicate of the link's text. Therefore the tooltip provided is of no value whatsoever. For users of assistive technologies, the title attribute is useless at best and sometimes an annoyance. Users of text-to-speech software who have configured their software to do so will hear the title attribute twice. Essentially the extensive use of title attributes throughout WordPress Core amounts to unnecessary code bloat. I recommend eliminating the title attributes from all of the methods below: {{{ // user.php wp_authenticate_username_password() // post-template.php wp_page_menu() wp_get_attachment_link() // media.php get_image_tag() // media-template.php wp_print_media_templates() // link-template.php edit_term_link() edit_post_link() edit_comment_link() edit_bookmark_link() get_adjacent_post_rel_link() the_shortlink() // default-widgets.php widget() // comment-template.php comments_popup_link() comment_form() // class-wp-theme.php markup_header() // class-wp-editor.php wp_fullscreen_html(). There is one title attribute here on what I think is a TinyMCE button. If that looks like a button, it should actually be a button. // class-wp-customize-section.php render() // category-template.php get_category_parents() get_the_category_list() wp_generate_tag_cloud() start_el() // bookmark-template.php _walk_bookmarks() // author-template.php get_the_author_link() the_author_posts_link() wp_list_authors() // rss.php wp_rss() get_rss() // general-template.php get_calendar() // class-wp-admin-bar.php _render_item() }}} * Note: Ignored: All Third party classes " karlgroves Unpatched Enhancements 53356 Themes admin page: make theme details, active, and preview links always visible Travel_girl Themes normal normal Future Release enhancement assigned 2021-06-07T23:21:42Z 2024-01-29T20:21:48Z "Follow up from #52649 In ticket 52649, we fixed a number of accessibility issues in the theme navigation. In the course of discussing that, there was a proposal to modify the layout so that the three action buttons for a theme were always visible, without obscuring the theme screenshot. Since it was beyond the scope of the original ticket, we opted to complete that ticket and open the design issue as a new ticket. See: https://core.trac.wordpress.org/ticket/52649#comment:15 https://core.trac.wordpress.org/ticket/52649#comment:27 " joedolson Slated for Next Release 60726 The WordPress core password reset needs to pre-populate the username to meet WCAG 2.2 joedolson* Login and Registration normal normal 6.6 defect (bug) accepted 2024-03-07T17:09:25Z 2024-03-07T19:33:35Z "According to new WCAG 2.2 success criterion for [https://www.w3.org/TR/WCAG22/#dfn-processes 3.3.7 redundant entry]. The criterion establishes that information previously entered by or provided to the user that is required to be entered again the same process is either: * auto-populated, or * available for the user to select There are 3 exceptions: * re-entering the information is essential, * the information is required to ensure the security of the content, or * previously entered information is no longer valid. Once the user has performed the process of requesting a new password, the redirected form should have the username filled-in to pass. As of now, this is the form that the user is redirected to: " estelaris Slated for Next Release 40331 The placeholder attribute should not be used as a replacement for a label joedolson* Administration normal normal 6.6 defect (bug) accepted has-patch 2017-04-01T16:37:45Z 2024-03-01T22:04:02Z "This is the second ticket in the `a11y-task` series, which aims to start a discussion and research on broad accessibility issues. See also #40330. Across the WordPress admin, the placeholder attribute is used in an inconsistent way. Sometimes it's used properly, sometimes not. For example, this is a good usage because the form fields have a visible label and the placeholder clarifies the expected format: [[Image(https://cldup.com/G8zSR9UYzm.png)]] [The ""Post via email"" section in the WordPress Writing Settings] In other cases though, the placeholder attribute is used as a replacement for a label. While it's tempting for designers to use it this way, especially when screen real estate for a visible label is limited, this practice introduces accessibility (and usability) barriers and goes against the HTML5 specification. Despite the fact labels and placeholders have distinct (and complementary) purposes, replacing labels with placeholders has become, unfortunately, a popular practice. In the accessibility team we've discussed this issue a few times, and we'd like to propose to make an effort to change the current approach when using placeholders. Basically, the only use case when a placeholder used as a visual label can be considered acceptable, is when there's just one, simple, form field and its purpose is made very clear by the context. For example, a search field. [https://make.wordpress.org/core/handbook/best-practices/coding-standards/accessibility-coding-standards/ WordPress aims to be as much accessible as possible], I'd say a good first step would be striving to conform to the WCAG and HTML5 specifications. One more good step would be avoiding to introduce new cases where the placeholder attribute is misused . There are lots of resources online about the placeholder issue, so I'd prefer to keep this ticket description short and refer to them, starting with what the HTML5 specification says: https://www.w3.org/TR/html51/sec-forms.html#the-placeholder-attribute > The placeholder attribute represents a short hint (a word or short phrase) '''intended to aid the user with data entry''' when the control has no value. A hint '''could be a sample value or a brief description of the expected format'''. > '''The placeholder attribute should not be used as a replacement for a label.''' For a longer hint or other advisory text, place the text next to the control. And then, in a big red-bordered box: > '''Warning'''! Use of the placeholder attribute as a replacement for a label can reduce the accessibility and usability of the control for a range of users including older users and users with cognitive, mobility, fine motor skill or vision impairments. While the hint given by the control’s label is shown at all times, the short hint given in the placeholder attribute is only shown before the user enters a value. Furthermore, placeholder text may be mistaken for a pre-filled value, and as commonly implemented the default color of the placeholder text provides insufficient contrast and the lack of a separate visible label reduces the size of the hit region available for setting focus on the control. Other resources: W3C Web Accessibility Tutorials https://www.w3.org/WAI/tutorials/forms/instructions/#placeholder-text W3C WAI Wiki: Using @placeholder on input http://www.w3.org/WAI/GL/wiki/Using_@placeholder_on_input Léonie Watson: Using the HTML5 placeholder attribute http://tink.uk/using-the-html5-placeholder-attribute The Paciello Group. HTML5 Accessibility Chops: the placeholder attribute http://www.paciellogroup.com/blog/2011/02/html5-accessibility-chops-the-placeholder-attribute/ WebAIM: Creating Accessible Forms http://webaim.org/techniques/forms/advanced Nielsen Norman Group. Placeholders in Form Fields Are Harmful http://www.nngroup.com/articles/form-design-placeholders/ Roger Johansson - 456 Berea Street. The HTML5 placeholder attribute is not a substitute for the label element http://www.456bereastreet.com/archive/201204/the_html5_placeholder_attribute_is_not_a_substitute_for_the_label_element/ Web Axe: Placeholder Attribute Is Not A Label! http://www.webaxe.org/placeholder-attribute-is-not-a-label/ Mobile Form Usability: Never Use Inline Labels https://baymard.com/blog/mobile-forms-avoid-inline-labels See the ""Exceptions"" paragraph " afercia Slated for Next Release 47682 "The links ""hover"" color has insufficient color contrast" joedolson* Administration normal normal 6.6 task (blessed) accepted 2019-07-11T12:32:43Z 2024-02-06T15:50:53Z "Supersedes #35622 and #47157. During the contributor day at WCEU 2019, it was proposed to merge #35622 and #47157. They're strictly related and the root issue needs to be tackled holistically across the whole WordPress admin. == Problem Default links (and ""button-links"") in WordPress are blue. The ones for destructive actions are red. Generally, the default colors for their normal state do have a sufficient color contrast ratio of 4.5:1 with the background. However, the colors used for the ""hover"" (and ""active"") state don't. == Relevant standard W3C Web Content Accessibility Guidelines (WCAG) [https://www.w3.org/TR/WCAG21/#contrast-minimum 1.4.3 Contrast (Minimum) (Level AA)] == Details #35622 dived into the red links issue and after some exploration it became clear that finding a color **pair** (one color for the normal state and one for the hover/active state) that always works across the admin, is nearly impossible given the several, different, background colors used in the admin pages. Part of the problem is that the hover color is ""lighter"" than the default one. Worth noting the color used for the ""focus"" state is darker instead. More importantly, there are several different background colors, including [https://core.trac.wordpress.org/ticket/35783 an arguable amount of grey shades]. Trying to summarise the reason why #35622 didn't progress: - darkening the ""hover"" red forced to darken also the default red - once a new color pair was identified, it worked well on ''some'' backgrounds - however, it didn't work on other darker backgrounds - started from scratch and further darkened the color pair - it worked on more backgrounds - found edge cases - darkened the color pair again - at some point the normal red was so dark to look almost ""brownish"" - failure The same problem applies to the blue links, as reported in the WPCampus accessibility report. See #47157. == Some examples **The ""hover"" blue `#00a0d2`:** 3.02 contrast ratio on white background 2.67 contrast ratio on the admin default grey background `#f1f1f1` 2.87 contrast ratio on the tables zebra-stripe grey `#f9f9f9` **The ""hover"" red `#dc3232`:** 4.62 contrast ratio on white background (which is OK) 4:39 contrast ratio on the tables zebra-stripe grey `#f9f9f9` 4.09 contrast ratio on the default grey `#f1f1f1` 4.16 contrast ratio on media views grey `#f3f3f3` 3.98 contrast ratio on customizer grey `#eee` Note: these are just a few examples. There are more background colors to take into consideration and also edge cases, e.g. the yellow background for unapproved comments. == Some screenshots [[Image(http://cldup.com/q5MYm6DKL1.png)]] [[Image(http://cldup.com/rawfy7Eth9.png)]] [[Image(http://cldup.com/IoW1cBF-Pl.png)]] [[Image(http://cldup.com/PGDfF4zXTZ.png)]] [[Image(http://cldup.com/PMx2qmF8zQ.png)]] [[Image(http://cldup.com/Kgp8htI4g5.png)]] [[Image(http://cldup.com/vdAtUeFEyZ.png)]] == Questions and possible options - Does the hover state needs to be communicated with a color change in the first place? - If so, does the hover color needs to be ""lighter""? Using the darker color already used for the ""focus"" state may help. Generally, the color used for the hover state shouldn't be ""lighter"", as that reduces contrast right in the moment when users need it the most. - Are there better ways other than a color change? For example: toggling the link underline, or using a border, or an additional shape, would allow to use just one color and greatly simplify things. == Background colors Background colors are an important part of this problem. I do realise design considerations led to use different background colors in different parts of the WordPress admin. For example, the media views and the customizer made some autonomous design choices for their background colors. There are historical reasons for that. However, this led over time to a great inconsistency across the admin. For the greater good of maintenance, consistency, and simplification, I'd strongly suggest to start by exploring a way to drastically standardise the shades of grey used as background in WordPress. Ideally, there shouldn't be more than 3-4 shades of ""light"" grey used for the background. Some work in this regard was done in #35783 but there's still a lot of work to be done. == Note on accessibility standards for links According to [https://make.wordpress.org/core/handbook/best-practices/coding-standards/accessibility-coding-standards/#links-underline-or-no-underline the WordPress accessibility coding standards]: > When links can be identified as such by the context, for example because they're part of a menu, or a set of links clearly identified as user interface controls, they don't necessarily need to be underlined. In all the other cases, especially for links surrounded by other text (in a line or block of text), links need to be always underlined. " afercia Slated for Next Release 60158 The description field for media doesn't automatically make paragraphs in the generated code joedolson* Media normal normal 6.6 defect (bug) accepted needs-unit-tests 2023-12-27T11:47:53Z 2024-03-19T15:20:16Z "There are two ways to edit a media: - via a modal window where all the contribution fields are only simple textareas; - via a dedicated web page where ""alternative text"" and ""caption"" fields are simple textareas and the ""description"" field is a WYSIWYG editor in text mode where TinyMCE is deactivated. For some media, you can need to add a long description just like a transcript (for videos, audios, complex images like infographic, etc.). So, in these cases, the description field can be used because it's totally appropriate. But, there is a problem: usually, in editor fields, the paragraphs (

elements) are automatically added when you display the web page (in the front view). In this field, they are not. For accessibility reason, paragraphs need to be HTML paragraphs ([https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html WCAG Success Criterion 1.3.1: Info and Relationships (level A)]). I've tried to modify the code in the core to add TinyMCE that is explicitly deactivated and this is fixing the problem. It's in wp-admin/includes/media.php, on line 3261 where you can just change ""false"" to ""true"" for ""tinymce"": {{{#!php 'strong,em,link,block,del,ins,img,ul,ol,li,code,close' ); $editor_args = array( 'textarea_name' => 'content', 'textarea_rows' => 5, 'media_buttons' => false, 'tinymce' => false, 'quicktags' => $quicktags_settings, ); }}} So, is it possible to activate TinyMCE for this field? Why is it deactivated? Or, if it's not possible, is it possible to make this option hookable? Thank you " juliemoynat Unpatched Bugs 47144 Text inadvertently rendered by assistive technologies joedolson* Media normal normal Future Release defect (bug) accepted 2019-05-06T14:58:01Z 2022-10-28T15:49:23Z "Moved from the WPCampus accessibility report issues on GitHub, see https://github.com/WordPress/gutenberg/issues/15296 * **Severity**: * Medium * **Affected Populations**: * Blind * Low-Vision * Cognitively Impaired * **Platform(s):** * Windows - Screen Reader * Mac - VoiceOver * Android - TalkBack * iOS - VoiceOver * **Components affected**: * Block Panel * Document Panel * Media Dialog **Issue description** Users of assistive technologies such as screen readers who navigate to the bottom of the Settings panels will find a button which they cannot activate (nor see if sighted) called ""Select files"". Additionally, if users change the color modes in the popup custom color picker, the current mode is announced in a live region. However, long after users are done with choosing a color, even after choosing to edit another block on the page, when they reach the bottom of the Block panel they'll still hear ""hex color mode active"". At this point, users may not remember what this was for and have no idea what this is referencing, as it no longer has any context. **Issue Code** {{{

Hex color mode active
}}} **Remediation Guidance** When users have performed an action, such as clicking another block (or whatever action causes ""No block selected"" to appear in the Block panel), clear the live region so that users who encounter it while manually reading do not hear it. Refill the live region when users change color modes. The hidden file selection button should be hidden from all users with display: none whenever it is not visible nor meant to be used. **Recommended Code** {{{
}}} **Note**: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by Tenon and funded by WP Campus. This issue is GUT-41 in Tenon's report ''**Note**: The a11y-speak live regions are used in core as well. In several places. Thus, clearing the live regions shouldn't depend on a specific user action or scenario. It would require a more generic solution, preferably avoiding setTimeout() which seems to me a very fragile solution by its own nature.''" anevins Unpatched Bugs 25103 Submit buttons on form fields in the Add Media panel joedolson* Media 3.5 normal normal Future Release defect (bug) accepted 2013-08-20T21:23:11Z 2021-05-21T15:57:23Z "Splitting this out from #23561 There is no Go or Search button available to trigger the action for the search and filter input fields in the Add Media screen - both of which change the content of the panel below. For accessibility reasons the user should be in control of triggering the filtering." johnbillion Slated for Next Release 60369 Shortcut for Select Button in Media Library antpb Media normal normal 6.6 enhancement assigned 2024-01-29T11:58:30Z 2024-03-07T19:34:39Z "Hi there, there should be a shortcut to confirm the selected image in Media Library? It is possible to choose an image with Return Shortcut but there is no combination (and documentation) to just confirm the selection with keypad and insert it to the page … Dealing with lots of images is currently really cucumbersome, as one has to click the button manually each time again and again. [https://pasteboard.co/sX5B35Ns3tM7.jpg]" hirschferkel Unpatched Enhancements 16413 Settings page needs HTML refactoring and UI improvements joedolson* Administration 3.1 normal normal Future Release enhancement accepted 2011-01-30T20:22:09Z 2023-11-10T16:20:51Z "The settings pages haven't had much attention or improvement in a while. We need to refactor the HTML on the settings pages, as they are still using tables instead of divs. We also want to make some minor UI improvements including: - clearer differentiation between option groupings - using consistent text styles for descriptions and links (including the time zone/date format comment) - restructure for better readability Comment if you have any other" chexee Unpatched Enhancements 52288 Separate Color Palette for Text sarahricker Editor normal normal Future Release enhancement assigned 2021-01-13T09:22:54Z 2021-05-21T15:39:45Z "It would be great with a separate Theme Support feature to be able to add a color palette for text colors only. It is often not a good feature to allow the average user to have access to a lot of colors that can be mixed in any way. Readability can be discarded. add_theme_support( 'editor-text-color-palette' , [ ... ] ); add_theme_support( 'editor-color-palette' , [ ... ] ); " jontng Unpatched Enhancements 26504 Semantic elements for non-link links joedolson* Administration 3.8 normal normal Future Release task (blessed) accepted 2013-12-09T14:29:18Z 2024-01-30T15:12:56Z "Using the [http://heydonworks.com/revenge_css_bookmarklet/ revenge.css bookmarklet] on the dashboard gives a very [http://d.pr/i/yVYh clear indication] that some of the links on there are semantically incorrect - they should be buttons, even if they should look like links. The Actual Buttons Are Actual section of this [http://coding.smashingmagazine.com/2013/08/20/semantic-css-with-intelligent-selectors/ article] sums it up nicely why. Unless the accessibility team have indicated otherwise, each of the 74+ occurrences (only counting PHP files, more in JS files) of links with `href=""#""` should probably be a `
// Basic CSS: .no-button { background: none; border: none; color: #0074a2; } .no-button:hover { color: #2EA2C9; cursor: pointer; } " GaryJ Unpatched Bugs 39793 Scrolling up in the sticky post text editor does not scroll the page up to top Editor normal normal Future Release defect (bug) new 2017-02-06T13:03:53Z 2019-06-05T06:52:24Z "In the sticky post editor, if I use arrow keys to navigate in the text mode tab (textarea#content), the page does not scroll up to the very top of the page, leaving part of the text hidden. I have to use mouse to again reveal the text. In the TinyMCE mode the scrolling works perfectly. I attached a screenshot where I created lines of text to get the page scroll. At the bottom of the page, cursor can be seen all the time. Then, when I go and use arrow keys to scroll to the first line of the text, it only scrolls almost to the top, leaving about 6.5 lines above the scroll. Additionally, using Ctrl+Home or Ctrl+End (on Windows) to navigate to the top or bottom of the textarea does not scroll the page." elmo5 Tickets with Patches 47670 RSS widget creates an accessibility problem when used more than once audrasjb Widgets normal normal Future Release defect (bug) reviewing dev-feedback 2019-07-09T18:49:02Z 2021-11-12T17:46:02Z "Please consider the following patch to improve accessibility. Accessibility guidelines in WCAG's standard 2.4.4 Link Purpose requires that link text should provide a purpose or context for the link. In the RSS widget, the link text for the link to the RSS feed itself is an image of the RSS icon; its alt text is ""RSS"" which programmatically determines the link text. This passes the referenced standard. A problem occurs when multiple instances of the RSS widget are used. There are then multiple links with link text ""RSS"", each of which lead to different URLs. The text ""RSS"" then does not provide enough context for visitors to know what each ""RSS"" link leads to. The solution is the make each RSS link text unique to each feed's title, thus providing the necessary context. Simply prepending the title of the widget instance adds the necessary context to the link text without using any additional words which could has i18n issues. In class-wp-widget-rss.php (lines 89-91 in 5.2.2): From: {{{#!php ' . esc_html( $title ) . ''; } }}} To: {{{#!php ' . esc_html( $title ) . ''; } }}} No harm is done when only a single instance of the RSS widget is used because the RSS link text is simply more explicit." tpaw Unpatched Enhancements 23432 "Review usage of target=""_blank"" in the admin" sabernhardt* Administration 3.2 normal normal Future Release task (blessed) accepted 2013-02-09T15:26:25Z 2023-11-17T17:54:28Z "Some links in the Setting Pages (General, Discussion, Permalink) pages open in same window, which sometime can be awful. [[BR]] While the users can press cmd/ctrl + click and click the link to open it in new tab but If the user does not open the link in new window, options (which are not saved) will be lost and one have to go through them again.[[BR]] Also links in the Edit Profile page and all the links in the help tab open in new window except a few.(so it is possible that users may just click it thinking them to alike other links which open in new window)[[BR]] So a consistency will be there and ux can be a little better." theadityajain Unpatched Enhancements 40925 Review the usage of the change event on select elements joedolson* Administration normal normal Future Release task (blessed) accepted 2017-06-05T12:47:01Z 2023-09-22T16:09:18Z "See also #31634 The change event can be problematic when used on select elements because browsers fire the event in different ways across different platforms. In this ticket I'll try to clarify what this difference is, why it matters for keyboard users, and why some actions shouldn't be triggered when a select option gets selected. On macOS, when using the keyboard to navigate content and a select element gets focused, using the arrow keys always opens the select ""drop-down"": [[Image(https://cldup.com/rU6roN4wAO.png)]] This behavior allows users to explore the content of the select, scroll through the options, and select an option pressing Enter or Spacebar. This way, the change event fires after an explicit user action. Instead, on Windows using the arrow keys on a select doesn't automatically open the ""drop-down"". To clarify what happens, I've made a short video using the Archives and Categories widgets as an example: https://cloudup.com/iuFxQ7CkA7k Historically, this behavior was typical of all browsers on Windows, except Firefox. However, a recent change made Firefox behave like all the other browsers. For more details, see https://bugzilla.mozilla.org/show_bug.cgi?id=1350700 Since the drop-down doesn't open (it does only when pressing Alt+Down arrow), it's hard to scroll the list of options without firing the event at each arrow keys press. Users would need to explore the content of the select before making a choice, and to do so they use the arrow keys. However, while exploring the select content, the action associated to the change event runs. In the case of these widgets, the action triggers a full page reload. Actions that have a big impact like a full page reload or a complete change of context should only be triggered after an intentional choice of the user, i.e. when pressing a button close to the select. In other cases, when the action triggers minor changes, using the change event could be OK. The best option would probably be to evaluate the interaction on a case by case basis. There are a few places in WordPress where the change event is used this way, not pretending to be a complete list, here's some of them: Media views: - Filter by type - Filter by date Customizer - Menu > Menu locations - Static front page > A static page" afercia Tickets Needing Feedback 43178 Rethinking what “captions” means for video postphotos Media 5.1 normal normal Future Release enhancement assigned reporter-feedback 2018-01-29T16:32:59Z 2023-10-19T18:38:35Z "'''Because different users will use the word ""caption"" in different ways, it would be helpful to look at reducing this term in WordPress media and clarifying all media terms as a whole.''' Captions carry a meaning in the video industry that is closely related to subtitles. It's recommended that we change how we describe our images, videos, and other media used within WordPress. ''Note: For architectural reasons, the field data should be left alone, but we need a better label for the associated meta. I also talked about this a bit in #31177'' This proposal further explores the messy language in media attachments and focuses on clear description so that all users can understand them, including clarifying WordPress' use of video subtitles. A proposal to revising these terms is below. Images 1) Wherever images use {{{data-setting=""title""}}} - instead of ""Title"" the English label should read ""Media Title."" 2) Wherever images use {{{data-setting=""caption""}}} - instead of ""Caption"" the English label should read ""Image Caption."" Because the specific term ""photo captioning"" describes a widely-used industry term, it should be clarified here but not removed. 3) Wherever images use {{{data-setting=""description""}}} - instead of ""Description"" the English label should read ""Longer Description."" This is because theme developers do not output this data beyond attachment pages and having three ill-described content areas - alt, caption, description - is an anti-pattern to describe what these images. Videos 1) Wherever images use {{{data-setting=""title""}}} - instead of ""Title"" the English label should read ""Media Title."" 2) Wherever video use {{{data-setting=""caption""}}} - instead of ""Caption"" the English label should read ""Media Description."" 3) Wherever images use {{{data-setting=""description""}}} - instead of ""Description"" the English label should read ""Longer Description."" This is because theme developers do not output this data beyond attachment pages and having three ill-described content areas - alt, caption, description - is an anti-pattern to describe these images. By adjusting these terms and exposing utility of the meta values, this level of clarity will greatly enhance the ability for all users, especially those helping create content for both multi-lingual and Deaf audiences, to understand the meta values in managing media work without the need to read documentation. Goals: 1. Because videos are reused on separate posts and all subtitled videos should contain this as a part of their output, create a meta value (or some other object type) that stores associated SRTs per language. 2. Allow for a better way for all videos that stores the associated SRTs to be associated with a language or as another kind of subtitle track - i.e. commentary, descriptive text, etc. 3. Allow videos uploaded at the same time with the same subtitle file name (or in a language structure) to be associated with each other. Assume the default core language for videos with no LANG code and associate the only subtitle as belonging to default core’s. (If there’s only one SRT with no lang suffix, it’s probably a caption.) If we leave the existing labels as-is, new and old users will both continue to put the wrong information in because of the lack of context to each field. Whatever fix we decide on, this should also be further adjusted in each target language that WordPress core is released in." postphotos Tickets Needing Feedback 36447 Responsive preview icons in Customizer need tooltips iamjolly Customize 4.6 normal normal Future Release enhancement assigned dev-feedback 2016-04-08T02:44:59Z 2021-11-09T15:43:27Z "The new icons at the bottom of the Customizer for toggling the preview window of your site really need tooltips to indicate what they're for. Just like the tooltips on the Visual Editor icons, other icons in the Dashboard should have tooltips as well. As leading usability expert Jakob Nielsen explains; >A user’s understanding of an icon is based on previous experience. Due to the absence of a standard usage for most icons, text labels are necessary to communicate the meaning and reduce ambiguity. https://www.nngroup.com/articles/icon-usability/ Even the Google Design Guidelines recommend tooltips for icons https://www.google.com/design/spec/components/tooltips.html# I originally raised this as a post on the [https://wordpress.org/support/topic/responsive-preview-icons-in-customizer-need-tooltips Beta forum] but it was suggested that since it's getting late in the 4.5 release cycle it would be best to raise it as a Trac ticket." ahortin Slated for Next Release 59965 Reply link: Elements with visible text labels do not have matching accessible names Comments 4.1 normal normal 6.6 defect (bug) new 2023-11-26T04:17:54Z 2024-03-05T15:59:12Z "Hi, When I scanned the page with PageSpeed ​​Insights, it gave the following error for reply link: Elements with visible text labels do not have matching accessible names. aria-label problem. Because it is the same as the text. I solved it like this: I edited line 1822 in the wp-includes/comment-template.php file. I deleted it to be empty inside the quotes. The problem is fixed. I hope it will be fixed in new updates. Topic: https://wordpress.org/support/topic/reply-link-elements-with-visible-text-labels-do-not-have-matching-accessible-na/" halilesen Unpatched Enhancements 49930 Replace wp-admin color schemes with CSS custom properties Administration normal normal Future Release enhancement new 2020-04-17T09:41:44Z 2022-06-02T14:45:07Z "There has been some discussion in the #core-css channel on Slack around changing the colours used for the colour schemes to use CSS Custom Properties. There are a number of complexities and issues that need to be considered before this could happen. This ticket is to capture those conversations here. CSS custom properties have a lot of benefits including future-proofing for when media queries focussing on accessibility features are more heavily used. For example: `@media (prefers-color-scheme: dark) {}` However, the biggest drawback with using CSS Custom Properties is the lack of support in older browsers: https://caniuse.com/#feat=css-variables shows no support for IE 6 - 11 and therefore a strategy for this would also have to be considered. Some tickets/resources that already exist that could affect this discussion are: - https://core.trac.wordpress.org/ticket/26691 Admin Color Schemes: generic classes for colors - https://github.com/ryelle/admin-color-schemes / https://wordpress.org/plugins/admin-color-schemes/ Admin colour schemes plugin - https://wordpress.org/plugins/dark-mode/ Dark mode feature plugin (This is not an exhaustive list, only what has been mentioned in Slack already) Also see this discussion in Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1586792806203800 and https://wordpress.slack.com/archives/CQ7V4966Q/p1586793176207300" kburgoine Tickets Needing Feedback 10955 Replace ThickBox External Libraries 2.9 normal normal Future Release enhancement reopened dev-feedback 2009-10-14T14:37:42Z 2023-11-10T16:01:17Z "Have you thought about replacing ThickBox? It is no longer under development (as their site says) and it doesn't conform to standard jQuery plugin practices. For example, I'm trying to use it for a plugin of mine and I'm wanting to tie into the ""onClose"" event for ThickBox which isn't too easily done. I know I could just include one of the other plugins, like colorbox, with my plugin but I think it'd be a great service to other developers if you included a more flexible library. (I would have assigned this to 3.0+ but the option isn't available.)" aaron_guitar Tickets with Patches 38061 Rename the text window name on the editor Editor normal normal Future Release enhancement assigned has-patch 2016-09-14T22:10:52Z 2019-06-21T06:36:36Z "The text window on the editor name should be something that makes better sense to new users. Since the reality is it is a way to tab between the visual editor and actual view the code. So if a new user who does not know this if they tab between Visual and Text it does not make total sense." lukecavanagh Unpatched Enhancements 52399 Remove widget accessibility mode joedolson* Widgets normal normal Future Release enhancement accepted 2021-01-29T16:44:29Z 2021-10-30T19:51:07Z "With the introduction of the new block editing experience for widgets management, WordPress will have four separate interfaces for managing widgets: block editing, customizer, classic widgets, and accessbility mode. The accessibility team would like to explore merging the characteristics that accessibility mode uses for better accessibility into the classic widget screen, to cut down to only three modes of operation for widgets. This will require identifying the characteristics of accessibility mode and finding ways to reproduce those characteristics within the existing widget UI. The key differences that are obvious are: 1) Use of a text link to 'Add' or 'Edit' 2) Links target each widget via a URL to manage independently. 3) Selection options to choose which sidebar and position will be used for a widget. These characteristics allow a single widget to be edited in isolation, the ability to assign a location without drag and drop, and visible text tools for handling widgets. One possibility to explore is having an add/edit option that opens a given widget in a modal that includes the location selection tools provided in accessibility mode. " joedolson Tickets with Patches 51299 Remove the title attribute from Walker_Nav_Menu Hareesh Pillai Menus normal normal Future Release defect (bug) assigned has-patch 2020-09-13T07:43:17Z 2021-08-05T00:29:59Z "As highlighted in [https://make.wordpress.org/accessibility/2020/08/25/accessibility-teams-goals-for-wordpress-5-6-and-beyond/#comment-73002 one of the comments] for the `Accessibility Team’s goals for WordPress 5.6 and beyond` post, the title attribute has to be removed from nav walker menus. This creates repetitive screen reader announcements for some screen reader/browser combinations. " Hareesh Pillai Tickets with Patches 60100 "Remove target=""_blank"" from link for non-HTTPS local environments" Application Passwords 5.9 normal normal Future Release defect (bug) new has-patch 2023-12-18T20:28:01Z 2024-03-23T19:50:19Z "Related: #23432, #53658 The developer docs link for [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/user-edit.php?rev=56798#L855 enabling Application Passwords] in non-HTTPS local environments probably should not open in a new tab. While losing changes is currently possible when the link opens in the same tab, that should have a different solution for //any// links clicked on the User Profile page (#40493)." sabernhardt Slated for Next Release 60097 "Remove target=""_blank"" from help tab in privacy-related screens" joedolson* Help/About 5.7 normal normal 6.6 defect (bug) accepted has-patch 2023-12-18T20:16:07Z 2024-03-12T15:56:53Z "Related: #23432, #43994, #52970 Several help links have stopped opening in a new tab/window (ticket:23432#comment:36). Similarly, the links for how to add plugin support of either exporting or erasing personal data should not force opening in a separate tab." sabernhardt Slated for Next Release 60479 Remove adminbar skiplink focus fix joedolson Toolbar 3.5 normal normal 6.6 defect (bug) assigned has-patch 2024-02-08T21:17:55Z 2024-03-19T15:22:33Z "The webkit-only skip link target fix for the adminbar is no longer required. The equivalent fix has already been removed from core themes (in #54421), and we should also remove it from the Admin bar. Was added in r22249. " joedolson Unpatched Enhancements 52480 Refine the display of the comment approval notification opt-in confirmation message Comments normal normal Future Release enhancement new dev-feedback 2021-02-09T17:09:29Z 2021-04-09T15:36:56Z "Follow-up to #52406. The confirmation message shown to a user ''after they opt-in'' to receiving a notification of their pending comment's approval is currently displayed inline with a preview of their comment. This means the display of this confirmation message is only shown if the user opts in within 10 minutes of posting their comment. If they take longer than 10 minutes then their opt-in is respected but they see no confirmation message. As mentioned in the comments in [comment:7:ticket:52406] 10 minutes is likely long enough but no research was done. Let's identify if this functionality needs to be improved. Options: * Extend the time limit further. This needs to take into consideration #49956. * Disconnect the display of the confirmation message from the comment preview, and always show a confirmation message. Would need to take into consideration the cache headers on the page. * Fix the comment spam problem some other way and remove the time limit. * Do something else. * Do nothing and leave it as-is. " johnbillion Unpatched Bugs 51419 Reconsider the UX impact of up/down arrows on meta boxes sarahricker Editor 5.5 normal normal Future Release defect (bug) assigned 2020-09-30T10:22:38Z 2022-06-03T19:35:11Z "In #39074 an accessibility problem was fixed whereby it was not possible to reorder meta boxes using only the keyboard. This is an important fix because it allows a keyboard-only user to reorder boxes in order to improve the tab order of these boxes. Unfortunately this created a side-effect where it's now easy to accidentally reorder a meta box by clicking on one of the up/down arrows, whereas previously you had to drag the meta box to another position to reorder it. There are a few UX issues related to this on the post editing screen: * Accidentally clicking the ""up"" arrow on the topmost sidebar meta box will cause it to move below the main post editing panel, which makes it easy to miss as it will commonly move well below the fold. I've just been dealing with reports from two separate users who did this and were unable to find the meta box. * Clicking anywhere on the meta box title expands/collapses it, but now there is also an up/down button that causes it to move position instead, in addition to the dedicated expand/collapse button. Users who are used to clicking the title now have to be careful where they click. * It's not possible to move block editor meta boxes (which are React components). This causes a significant visual discrepancy between ""classic"" meta boxes and block editor meta boxes, and causes especially strange behaviour when a user moves a meta box ""up"" and it doesn't actually move up to within the block editor meta boxes. ""Classic"" meta boxes aren't going away any time soon, so I think the last point is an important one." johnbillion Unpatched Enhancements 40330 Reconsider the usage of infinite scrolling across the admin Administration normal normal Future Release task (blessed) assigned 2017-04-01T14:24:24Z 2021-05-08T11:20:11Z "As accessibility team, we've often discussed and we're aware of some a11y issues in the WordPress admin but haven't formalized them in a Trac ticket yet. That's because they're general, broad, issues and they probably can't be solved soon, as they have a big impact on the way some relevant parts of the user interface are built. They would require some extensive discussion and research. Nevertheless, if we're not going to at least open a discussion, the solution is not going to happen 🙂 . During the last accessibility weekly meeting we've decided to open a series of tickets and use a special keyword to group them, something like `a11y-task`. This is the first ticket of the series. Infinite scrolling (sometimes known as ""endless scrolling"") can be a serious accessibility barrier. It's used in the admin in a few places, for example: - Media Grid - Add Themes screens - Customizer > Add menu items - Editor > Insert/Edit link > Search - any other places? For a comprehensive view of all the potential issues, I'd refer to the list of resources below. I'd recommend everyone to have a look at those posts. I'd say the issues can be grouped in three different categories: accessibility, usability, and performance. Just to mention some of the most relevant ones: - a11y: it's impossible or very hard for keyboard users to reach content placed after an infinite scrolling region: think for example at the Media Grid, where tabbing through attachments loads more and more attachments (potentially hundreds or thousands of them) forcing users to keep tabbing indefinitely - a11y: no audible feedback or instructions about how infinite scrolling works, the current and total number of items, or when new items get loaded - usability: infinite scrolling often breaks the browser's history - usability: there's no JS fallback - performance: memory footprint can be huge, especially when loading hundreds of big images, see the Theme install screens Resources mostly focused on accessibility: http://adrianroselli.com/2014/05/so-you-think-you-built-good-infinite.html http://simplyaccessible.com/article/infinite-scrolling/ http://www.webaxe.org/infinite-scrolling-and-accessibility/ http://www.ssbbartgroup.com/blog/infinite-scrolling-impact-on-assistive-technologies-series-1/ Resources mostly focused on usability: https://webmasters.googleblog.com/2014/02/infinite-scroll-search-friendly.html https://www.nngroup.com/articles/infinite-scrolling/ https://www.sitepoint.com/ux-infinite-scroll-good-bad-maybe/ http://www.webdesignerdepot.com/2015/11/how-infinite-scrolling-breaks-ux/ https://www.smashingmagazine.com/2016/03/pagination-infinite-scrolling-load-more-buttons/ https://www.smashingmagazine.com/2013/05/infinite-scrolling-lets-get-to-the-bottom-of-this/ Resources focused on memory footprint: http://engineering.linkedin.com/linkedin-ipad-5-techniques-smooth-infinite-scrolling-html5 https://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story/ http://dannysu.com/2012/07/07/infinite-scroll-memory-optimization/ Maybe for the future: the ARIA role `feed` https://www.w3.org/TR/wai-aria-1.1/#feed (at the time of writing, ARIA 1.1 is still a Candidate Recommendation, and as far as I know, no assistive technologies support the role `feed`) See also: http://www.ssbbartgroup.com/blog/differences-aria-1-0-1-1-additions-role/ See #19815, #28927, #28998. " afercia Tickets with Patches 47595 Re-evaluate whether comment form should still get the HTML5 novalidate attribute Comments 3.6 normal normal Future Release enhancement new has-patch 2019-06-24T08:15:42Z 2024-01-12T14:59:01Z "Given a theme that declares theme support for `html5` via: {{{#!php multi-file uploader page, newly added files are listed within rows after the uploader. The rows contain: - The attachment details, on the left. - Additional tools, on the right. There's a couple problems with that. == Proximity of controls The tools are displayed too far to the right, way far from the details. This is a problem, for example, for low vision users and users who use screen magnifiers, as the tools may be out of their vision field. Controls should be displayed visually grouped so that they can be easily discovered by all users. I'm not sure there's a good reason to have all that spacing between details and tools in the first place. == The Copy button shifts to the left when copying There's a few Copy buttons in use in the admin pages. Most of them are aligned to the left and there's a good reason for that: The UI must provide space for the 'Copied!' confirmation text. However, on this page the Copy button is aligned to the right. After a copy operation, the 'Copied!' text appears on the right of the button thus making the button itself shift to the left. I'm not sure having moving interactive controls on the screen is a good user experience. Instead, the Copy button should be placed in a way to reserve some space for the 'Copied!' text to appear without triggering a shift of other content. See screenshots and animated GIF below." afercia Tickets Needing Feedback 47012 Proposal: Simplify WordPress Admin Navigation Administration normal normal Future Release enhancement new dev-feedback 2019-04-22T15:40:53Z 2022-02-08T07:56:17Z "About 3 months ago [https://wordpress.slack.com/archives/C02S78ZAL/p1548265528434800?thread_ts=1548092047.364700&cid=C02S78ZAL joen shared some rough mockups] in Slack for proposed changes to the left sidebar navigation in core. My goal below (with Joen’s blessing) is to resurface those mockups a little more publicly to see if we can gather some more feedback and potentially gain a little more momentum with this project. === Summary The current sidebar has served us well for a long time. But with a few improvements, we can improve accessibility and usability, and allow it to better scale to extensions. === Challenges with the current design * The hover/flyout menus are difficult to make accessible, and they do not scale well to mobile interfaces. * There are a lot of top-level menu items that are rarely if ever used, contributing to cognitive weight by still being permanently visible. * Given the additional menu items that plugin add, people are likely to end up with many menu items, despite a large number of them perhaps not being used that often. === Mockup **Important disclaimer:** this is just an initial concept, it is subject to feedback and discussion and iterations: [[Image(menu-mockup.png)]] Props to joen for coming up with this v1 concept. === Major Changes * Flyout menus are replaced with accordion behavior. This scales all the way from mobile to desktop, and affords better accessibility. * Menu is made 80px wider (240px vs. 160), affording a 14px minimum font size for all items, perhaps bigger icons in the future, more relaxed spacing, enhancing usability and accessibility. * Sidebar is grouped in major sections, “Site”, “Design”, “Tools” and “Manage”. * “Updates” are moved to a subsection of “Manage”, making Home a single item. * Items related to content on your site (such as “Posts” and “Pages”) are moved under “Site”. * Clicking major menu items just opens or closes the accordion, as opposed to go directly to the first subsection. This unifies the mobile and desktop behavior. You can keep the accordion open if you use it all the time (each click will save state, so you’ll see the same open/closed sections upon page refresh). * All “Settings” subsections are moved under “Manage”, along with “Plugins & Blocks” and “Users”. * Separators group major categories, like “Site” and “Design” together * Dashboard is renamed “Home”, because all of WordPress is a Dashboard, and “Home” is where you can get an overview at a glance. === Custom Post Types & Taxonomies * Custom Post Types show up below Pages (top item) and Posts (2nd item). * A separator cordons these off from Media & Comments, which show content from all. * Categories & Tags, and even custom taxonomies, are accessible from each section, as opposed to having a permanent presence in the sidebar. For example if you have a taxonomy called “Ingredients” tied to “Recipes”, you first click “Recipes”, and on the archive page you can manage existing Ingredients under a tab. The argument for putting them under this page is that taxonomies are usually added in the editor itself, and only managed on the archive pages. * When you have custom post types, an additional, short, separator shows up below the post types. === Where's the ""Add New"" menu item? One idea would be to make this permanently visible in the top toolbar. [[Image(add-button.png)]] Clicking this button produces a dropdown. By moving it there, you have a single destination to create new content, and we reduce the amount of tab-stops in the navigation menu, especially for sites with a lot of custom post types. === Related Helen opened [https://core.trac.wordpress.org/ticket/32678 this ticket] over 4 years ago. There are a number of different ideas and threads in that ticket. If someone decides that these two tickets should be merged, that is fine. === Feedback Please keep in mind that this is just a ''very early, exploratory concept''. Nothing here is set in stone. The goal of this exercise would be to improve the overall usability and accessibility of the left nav. What thoughts, concerns, questions, and feedback do you have?" lessbloat Tickets Needing Feedback 48452 Proposal: improve distinction between buttons and other controls Administration normal normal Future Release enhancement new 2019-10-28T21:08:05Z 2021-03-02T16:32:57Z "New button styles were introduced in ticket #34904. As discussed in the comments on this blog post, [https://make.wordpress.org/design/2019/09/06/discussion-higher-contrast-form-fields-and-buttons/ Discussion: Higher contrast form fields and buttons], the secondary (or default) button style is no sufficiently distinct from input fields and other similar UI controls. This ticket attempts to remedy the issue and create a consistent styling of UI controls that is more usable. By seeing a set of UI controls together, we can figure out the best approach holistically. **The main concern that was raised is that the new default buttons are styled similarly to inputs, and it could be confusing for folks if they can't differentiate them.** Example: [[Image(http://cldup.com/wvn2VchDdY.png)]] Proposed solutions, compared directly: [[Image(http://cldup.com/vYhbr_PI36.png)]] - Option A: subtle background color, bold text - Option B: blue and bold text - Option C: subtle drop shadow, bold text In context, with more UI: Option A [[Image(http://cldup.com/7nma8vFVbm.png)]] Option B [[Image(http://cldup.com/XYDICcgCV7.png)]] Option C [[Image(http://cldup.com/bThhBvpVUp.png)]] --- Something to be considered separately from color and shadow is shape. What about using square corners for text inputs? [[Image(http://cldup.com/z8G9_qr_AX.png)]] Note: - These mockups do not include interactive states, although those will need to be explored. I think it's important these styles stand on their own first. - Testing these styles in the context of a real UI in WordPress will be the next step. - Please ignore labels and text. This is just to test the UI styling. - Text is using the default macOS system font. - Even though dark mode doesn't exist in WP, it's a good test to see how the styles hold up in an inverted color scheme. - I believe all proposed solutions meet AA color contrast guidelines. - Shadows will be removed it Windows high contrast mode, and we need some other visual indication other than color to distinguish the UI elements. This is my first ticket, so apologies if I missed any standard practices." drw158 Tickets with Patches 44267 Privacy Request List Table: A way to show the time of request when it's older than 24 hours. Privacy 4.9.6 normal normal Future Release enhancement new has-patch 2018-05-29T18:41:09Z 2019-01-27T07:21:19Z "When the request is older than 24 hours, then we can't see time of the request. An example: {{{ May 18, 2018 }}} The related methods are: - {{{WP_Privacy_Requests_Table::get_timestamp_as_date()}}}. - {{{WP_Privacy_Requests_Table::column_default()}}}. For comparison, here's an example from the ''posts'' list table in ''list'' view: {{{ 2018/05/14 }}} and in the ''excerpt'' view: {{{ Published
2018/05/14 8:41:52 am }}} Here's an example from the ''comments'' list table: {{{ 2018/04/20 at 5:35 pm }}} I'm not sure the {{{}}} is suitable here, after reading: https://stackoverflow.com/a/32892825/2078474 " birgire Unpatched Enhancements 55535 Pre-populate Image Alt Text field with IPTC Photo Metadata Standard Alt Text joedolson* Media normal minor Future Release enhancement accepted dev-feedback 2022-04-05T21:45:25Z 2024-02-05T20:52:37Z "The IPTC Photo Metadata Standard includes the ability to embed Alt Text with a photo. Seems like it would be helpful if WordPress would check for this data when an image is uploaded, and, if it exists, pre-populate the Alt Text field with it. I could see this being especially useful for site owners who purchase stock photography; if the alt text is embedded with those images, it would save the site owner time, and it would also help ensure that an Alt Text itself is added -- and is an accurate description of the image (assuming the photographer or stock photo site actually enters a good description!). http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#alt-text-accessibility" eatingrules Slated for Next Release 29838 Post editing area: keyboard accessibility, tab order and focus joedolson* Editor 4.0 normal normal 6.6 defect (bug) accepted 2014-10-02T16:27:31Z 2024-02-20T12:42:59Z "This ticket aims to focus on a specific area of the UI, let's call it ""Post editing area"", the one that starts with the ""Title"" field and ends with the editor area, both in ""Visual"" and ""Text"" mode. Related: #27553 while researching we noticed: > '''joedolson''': outstanding issues surrounding tab order, but this are long-standing and not relevant to this specific patch and issue; that needs to be raised separately. There's room for accessibility improvements here, especially when it comes to tab order and focus management. To fully understand what's going on you should stop for a while being a ""nervous clicker"" :) and: - apply the patch from #27553 - unplug your mouse and disable your trackpad :) - use just your keyboard - tab around, both forwards and backwards It would be great to test also switching off your display and using a screen reader, I would recommend Firefox and NVDA. Two main issues: Focus. When you're in the ""Title"" field and then you tab forwards, focus is moved directly inside the editor area skipping all what's in between. While this *may* be useful for sighted keyboard users (they save a few key presses, say 1 second?), it's a very critical experience for screen reader users: when they tab forwards, they get that right after the title there's the editor. But when they tab backwards, they get many more elements that ""weren't there before"". [https://core.trac.wordpress.org/ticket/27553#comment:17 more details on 27553 comments]. Tab order. The ""tabbing experience"" in Visual and Text mode should match as much as possible. Ideally, there should be a better [http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140902/G59 logical sequence in the markup]. When editing the title, the next logical step is editing the content, all the other controls (Add Media button, additional buttons provided by plugins and themes, etc.) should not be placed between the Title and the editor. The CEUX project proposed something similar at some point. There is ongoing research and development on the editing experience, see for example Editor Focus/DFW in #29806 and the idea to review relevant parts of the UI, see [https://make.wordpress.org/core/2014/10/01/agenda-for-october-1st-dev-chat/#comment-19392 explore moving the Publish | Save | Preview buttons out of the metabox, etc.] so it would be a great opportunity to explore this ticket too." afercia Slated for Next Release 60663 Plugin Cards: Links with `.button-disabled` are still clickable costdev Plugins normal normal 6.6 defect (bug) assigned has-patch 2024-03-01T03:04:20Z 2024-03-11T11:03:57Z "Props to @swissspidy for noticing this while testing Plugin Dependencies. Currently, links with a `href` attribute and the `.button-disabled` class are still clickable. We should prevent the default `click` handling for elements with the `.button-disabled` class. While this appears to have been the case in earlier WordPress versions, it may be more apparent in the increased AJAX-ified experience added by the Plugin Dependencies feature. **Milestoning for 6.5 for awareness, though I welcome thoughts on whether this is something that needs to be handled in 6.5, or should wait until 6.6.** == Testing Instructions These steps define how to reproduce the issue, and indicate the expected behavior. === Steps to Reproduce 1. Navigate to `Plugins > Add New Plugin`. 2. Click ""Install Now"". 3. Once installed, click ""Activate"". 4. 🐞 Once activated, click on the disabled ""Active"" button. === Expected Results When testing a patch to validate it works as expected: - ✅ The link does not work. When reproducing a bug: - ❌ The link still works despite the `.button-disabled` class being present." costdev Slated for Next Release 48710 PDF uploads are treated like images: empty alt attribute and PHP notices joedolson* Media normal normal 6.6 defect (bug) accepted dev-feedback 2019-11-18T20:42:21Z 2024-03-27T15:26:07Z "uploading a .pdf image in posts reads the following; ""this image has an empty alt attribute: its file name is.... .pdf"" I am a regular user since 1.5 versions of WP and this is my first bug, or error report. I tried downgrading, but it kept coming back error." worddean Slated for Next Release 40493 On the Edit User Profile page, prevent losing data when clicking links joedolson* Users normal normal 6.6 enhancement accepted has-patch 2017-04-20T12:08:37Z 2024-03-12T16:00:25Z "On the Edit User Profile, open the ""You can change your profile picture on Gravatar."" link in a new window. Reason being that otherwise it causes the user to loose any data that they have edited in the form, but not yet saved." ashokrane Unpatched Bugs 47105 Not focusing on input control when validate that input control Taxonomy normal normal Future Release defect (bug) new 2019-05-03T07:08:45Z 2019-06-28T14:23:13Z "This issue is generated in form validation (category,tag,taxonomy,etc...) in input controls. When anyone submits or save categories without a fill input box then showing red box validation but currently, it's not focusing validate a field (input field). Expected: When anyone submits or save category without fill input box then autofocus on validating input field that showing to the user to enter some value in the input box. Please follow this GIF steps: [[Image(https://s3.gifyu.com/images/screencast-localhost-2019.05.03-11-19-35.gif)]] " hardipparmar Slated for Next Release 59006 No title attribute on oEmbed and REST API s audrasjb Embeds 6.2.2 normal normal 6.6 enhancement reviewing has-patch 2023-08-08T19:24:56Z 2024-02-20T09:28:35Z "By default, WordPress adds three `` of every post. These are missing the `title=""...""` attribute. This means that some browsers will announce the links as ""alternate"" with no explanation of their destination - see screenshot attached. The three links are: {{{ }}} Ideally, these would have `title=""JSON""`, `title=""oEmbed (JSON)""`, `title=""oEmbed (XML)""` or similar." edent Unpatched Enhancements 35780 New data-type: recordable video General normal normal Future Release feature request new 2016-02-09T00:16:41Z 2019-06-04T19:55:20Z "Hello there I am suggesting a new data-type 'recordable video' within WordPress core. Do not have a clear idea what data types you currently have and how they are implemented. Already have raised this on slack and were recommended to raise this as a ticket instead. My goal is to make WordPress accessible for Sign Language users! They are mostly Deaf people who express their messages, comments, posts in Sign Language. Currently it is a pain to record a video message with a separate software, to convert, to compress and to upload it back to WordPress. That's not fair compared to those hearing people who just can type in the Form and submit that. There is an open source npm library to record videos, asynchronous, in plain JavaScript and HTML, see https://github.com/binarykitchen/videomail-client. Here is an exact example how this could work: https://binarykitchen.com/contact/action/add/ With the videomail-client you can add a recordable