zmuxuny opened a new issue, #7149: URL: https://github.com/apache/rocketmq-dashboard/issues/7149
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below. ### Studio Version rocketmq-studio at 127c47b06a268cc74224d5f34c56ec7c36ac0d55, built from source. ### Runtime Environment Linux cloud development environment; Node.js 24.19.0, Vitest/jsdom and the real Ant Design controls. Both Chinese and English modes. No screen-reader/browser deployment test is claimed. ### Connected RocketMQ Cluster Not required: this is client-side control naming, reproduced with the existing instance-service test fixture. ### Build Toolchain Node.js 24.19.0 / npm 11.9.0; installed project dependencies. ### Describe the Bug The Instance Management filter bar renders an Input with only a placeholder and an access-type Select without a label or aria-label. Their textbox/combobox accessible names are both empty. Operators using assistive technology cannot identify the purpose of either filter by its programmatic name. ### Steps to Reproduce 1. Render InstancePage in Chinese or English with its normal instance inventory fixture. 2. Inspect the search textbox and access-type combobox using Testing Library's toHaveAccessibleName. 3. Both assertions report an empty name. Repeat after selecting CLOUD with Tab, ArrowDown, Enter and clearing the search: filtering itself works, but neither control has a programmatic name. ### What Did You Expect to See? The search textbox and access-type combobox expose meaningful translated names, including when a value is selected or typed. Keyboard and filter request behavior remain unchanged. ### What Did You See Instead? Two bilingual real-component cases fail on four accessible-name assertions. The control cases for keyboard selection, combined search/type filtering, and clearing search pass. ### Additional Context All-state PR and issue searches found no equivalent change. Reviewed the broad accessibility/i18n patches #5586, #4635, #4806 plus nearby instance work #2485, #2674, #3982, #1997 and #6776; none labels these two controls. A minimal fix can reuse existing instance.searchPlaceholder and instance.accessType translations. Both controls belong to one coherent filter-bar change. This report does not claim keyboard operation is currently broken. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
