I did some testing with TalkBack on android, and I am fixing two issues to make it better: - https://chromium-review.googlesource.com/c/chromium/src/+/6937127 - https://chromium-review.googlesource.com/c/chromium/src/+/6952242
foolip also reviewed the spec PR On Wed, Sep 10, 2025 at 3:01 PM Joey Arhar <[email protected]> wrote: > > What's the status of the spec PR? > > I just updated the commit message and pinged a reviewer. > > > Do you know if this works as expected with screen readers? I imagine the > pop up style rendering works since that's currently a common experience, > but not sure what would happen in an in-page rendering on mobile? > > Thanks for bringing this up. I tested out the in-page listbox rendering on > android voiceover, and I found that the single-select worked fine but there > is something wrong with the multi-select mode. I am looking into it now. > > On Wed, Sep 10, 2025 at 8:15 AM Vladimir Levin <[email protected]> > wrote: > >> Do you know if this works as expected with screen readers? I imagine the >> pop up style rendering works since that's currently a common experience, >> but not sure what would happen in an in-page rendering on mobile? >> >> Thanks, >> Vlad >> >> On Thursday, September 4, 2025 at 9:55:18 PM UTC-4 Kent Tamura wrote: >> >>> LGTM1. The consistent behavior is reasonable, and the compatibility >>> risk looks very small. >>> >>> >>> On Fri, Sep 5, 2025 at 2:42 AM Joey Arhar <[email protected]> wrote: >>> >>>> Contact [email protected] >>>> >>>> Explainer >>>> https://github.com/whatwg/html/issues/8189#issuecomment-2877242732 >>>> >>>> Specificationhttps://github.com/whatwg/html/pull/11460 >>>> >>>> Summary >>>> >>>> By using the size and multiple attributes, the select element can be >>>> rendered as an in-page listbox or a button with a popup. However, these >>>> modes are not consistently available across mobile and desktop chrome. >>>> Currently, in-page listbox rendering is not available on mobile, and button >>>> with popup is not available on desktop when the multiple attribute is >>>> present. This feature adds the listbox to mobile and adds a multi-select >>>> popup to desktop, and makes the opt-ins with the size and multiple >>>> attributes result in the same rendering mode across mobile and desktop. >>>> Here is a summary of the changes: - When the size attribute has a value >>>> greater than 1, in-page rendering will always be used. Previously, this was >>>> ignored on mobile and always resulted in a popup. - When the multiple >>>> attribute is set with no size attribute, in-page rendering will be used. >>>> Previously, this was a popup instead of an in-page listbox on mobile. - >>>> When the multiple attribute is set with size=1, a popup will be used. >>>> Previously, this was an in-page listbox on desktop. By making this change, >>>> we are providing a foundation to bring customizable select to in-page >>>> rendering and multi-select. Customizable select currently only works for >>>> single-selects with a popup. >>>> >>>> >>>> Here is a screenshot of the new multi-select popup for desktop, which >>>> you'll get with <select multiple size=1>. This was created to reach parity >>>> with the previously existing multi-select popup on android. >>>> [image: 479732188-e42f4512-1059-4bae-85ed-00e2dee2a967.png] >>>> >>>> Blink componentBlink>Forms>Select >>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EForms%3ESelect%22> >>>> >>>> TAG reviewNone >>>> >>>> TAG review statusNot applicable >>>> >>>> Risks >>>> >>>> >>>> Interoperability and Compatibility >>>> >>>> Interop risk is low because of the positive standards position from >>>> Mozilla and the lack of blocking feedback from Apple in many standards >>>> discussions. There is a compat risk of breaking existing usage of select >>>> multiple on mobile which currently always uses a picker but will be changed >>>> to use the in-page listbox to match desktop. If there are any mobile sites >>>> relying on this particular rendering mode, they will have to add the size=1 >>>> attribute to their select element. I added a UseCounter to see how often >>>> users open a select multiple picker on mobile, and the usage is quite low: >>>> https://chromestatus.com/metrics/feature/timeline/popularity/5549 >>>> >>>> >>>> *Gecko*: Positive ( >>>> https://github.com/mozilla/standards-positions/issues/1274) >>>> >>>> *WebKit*: No signal ( >>>> https://github.com/WebKit/standards-positions/issues/532) >>>> >>>> *Web developers*: No signals >>>> >>>> *Other signals*: >>>> >>>> Ergonomics >>>> >>>> I expect the in-page rendering mode to be used in tandem with >>>> customizable select in the future when customizable select is expanded to >>>> include the in-page listbox rendering mode. The default usage of this API >>>> will not make it hard for chrome to maintain good performance. >>>> >>>> >>>> Activation >>>> >>>> It will not be challenging for developers to take advantage of this >>>> feature immediately. >>>> >>>> >>>> Security >>>> >>>> I don't believe there are any security risks for this feature. >>>> >>>> >>>> WebView application risks >>>> >>>> Does this intent deprecate or change behavior of existing APIs, such >>>> that it has potentially high risk for Android WebView-based applications? >>>> >>>> None >>>> >>>> >>>> Debuggability >>>> >>>> DevTools shows the attributes on the select element in the elements >>>> panel, but doesn't explain the logic for how the size and multiple >>>> attributes result in the different rendering modes. I expect this to be >>>> documented on MDN so developers can learn how to control this. >>>> >>>> >>>> Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, ChromeOS, Android, and Android WebView)?Yes >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ?No >>>> >>>> There is not a good way to test the native appearance of the select >>>> element, and there is no way to test whether the select element is in a >>>> mode which supports a picker or not. >>>> >>>> >>>> Flag name on about://flagsNone >>>> >>>> Finch feature nameSelectMobileDesktopParity >>>> >>>> Rollout plan(RARE) Experiment users ramp up over time >>>> >>>> Requires code in //chrome?False >>>> >>>> Tracking bughttps://issues.chromium.org/issues/439964654 >>>> >>>> Estimated milestones >>>> >>>> Finch in 141, enable by default in 142 >>>> >>>> >>>> Anticipated spec changes >>>> >>>> Open questions about a feature may be a source of future web compat or >>>> interop issues. Please list open issues (e.g. links to known github issues >>>> in the project for the feature specification) whose resolution may >>>> introduce web compat/interop risk (e.g., changing to naming or structure of >>>> the API in a non-backward-compatible way). >>>> None >>>> >>>> Link to entry on the Chrome Platform Status >>>> https://chromestatus.com/feature/5412736871825408?gate=6327273552740352 >>>> >>>> This intent message was generated by Chrome Platform Status >>>> <https://chromestatus.com/>. >>>> >>>> -- >>>> >>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwLEPi_ObWz9KhGJwsH2088%2BrDVJfUDFSin2SUBwNNkznw%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwLEPi_ObWz9KhGJwsH2088%2BrDVJfUDFSin2SUBwNNkznw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >>> >>> -- >>> TAMURA Kent >>> Software Engineer, Google >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btw%2BZw45a%2BkVdpS1Fa_ZE1g4uC4h10eThve3n_WJQbu7Ovw%40mail.gmail.com.
