Bugzilla

(In reply to Amy C from comment #11)
> Maybe the other elements need to change, too.

That's certainly possible!
 
With that broadening, that makes this potentially-more-actionable; but I still think we'd need a plan/design of some sort before making a change here, and some confidence that the approach is coherent.

One side note here: it looks like browsers are aligned on their behavior here right now (in the sense of not-honoring full-page-zoom for these components), as far as I can tell.  (Though if I'm missing something, please do mention that here, since other browsers' tested/proven approaches might be worth exploring or using as inspiration for whatever we end up doing here._

> it is frustrating to not be able to read a datalist, alert, date picker, etc

That's understandable.  Though it still feels inefficient/awkward to key this mitigation off of a [potentially] site-specific full-page zoom level, when the sizing itself is not site-specific.  I can see how in-the-moment you expect Full-Page-Zoom to work as an immediate mitigation, but it feels like it's a tool/band-aid that's not exactly right for this problem, and it creates some weird results.

E.g. suppose that, due to the page's font settings, your saved full-page-zoom level for https://www.wikipedia.org/ is 300%, whereas https://qz.com/ uses larger fonts and so you use the default 100% full-page-zoom level there. Does it really make sense for the browser to interpret these differing per-site full-page-zoom levels as a user-request that these various bits of browser UI (datepickers, alerts, datalist, maybe even context menu)  to render 3x as large on Wikipedia vs. on qz.com?  That doesn't make a lot of sense to me.

If these bits of UI are too small, it feels like the right fix here is to offer the user a way to directly fix that, rather than requiring them to use full-page-zoom every time they encounter these pieces of UI (which are, after all, fully under the browser's control).

One way that is **already** available to users is the OS resolution/font settings, as noted above.

I can also imagine that Firefox could provide an "override OS settings and use this minimum font in browser UI" option in its configuration (though I can imagine that'd get tricky if the user later makes an update to their OS settings and wonders why Firefox doesn't respect that).

Alternately, we could make all of this UI respond to full-page-zoom as you suggest, but that feels like the wrong tool for the job (even though it feels like it might be appropriate in a one-off encounter), as I've described above.

> Perhaps this needs to be reclassified rather than closed

Sure -- for now, I'll broaden the title a bit and reclassify this under our accessibility-features component; and if we end up with a plan of attack, we can further reclassify or spin off helper-bugs as appropriate.

(Also: if you feel like bits of Firefox UI like `datalist`/`calendar` are uniquely-inaccessible in Firefox and are easier to read in other browsers, that perhaps merits its own bug; & in that case, someone might also consider redesigning/scaling those components so that they're easier-to-read by default.)

(In reply to Amy C from comment #11)
> Maybe the other elements need to change, too.

That's certainly possible!
 
With that broadening, that makes this potentially-more-actionable; but I still think we'd need a plan/design of some sort before making a change here, and some confidence that the approach is coherent.

One side note here: it looks like browsers are aligned on their behavior here right now (in the sense of not-honoring full-page-zoom for these components), as far as I can tell.  (Though if I'm missing something, please do mention that here, since other browsers' tested/proven approaches might be worth exploring or using as inspiration for whatever we end up doing here.)

> it is frustrating to not be able to read a datalist, alert, date picker, etc

That's understandable.  Though it still feels inefficient/awkward to key this mitigation off of a [potentially] site-specific full-page zoom level, when the sizing itself is not site-specific.  I can see how in-the-moment you expect Full-Page-Zoom to work as an immediate mitigation, but it feels like it's a tool/band-aid that's not exactly right for this problem, and it creates some weird results.

E.g. suppose that, due to the page's font settings, your saved full-page-zoom level for https://www.wikipedia.org/ is 300%, whereas https://qz.com/ uses larger fonts and so you use the default 100% full-page-zoom level there. Does it really make sense for the browser to interpret these differing per-site full-page-zoom levels as a user-request that these various bits of browser UI (datepickers, alerts, datalist, maybe even context menu)  to render 3x as large on Wikipedia vs. on qz.com?  That doesn't make a lot of sense to me.

If these bits of UI are too small, it feels like the right fix here is to offer the user a way to directly fix that, rather than requiring them to use full-page-zoom every time they encounter these pieces of UI (which are, after all, fully under the browser's control).

One way that is **already** available to users is the OS resolution/font settings, as noted above.

I can also imagine that Firefox could provide an "override OS settings and use this minimum font in browser UI" option in its configuration (though I can imagine that'd get tricky if the user later makes an update to their OS settings and wonders why Firefox doesn't respect that).

Alternately, we could make all of this UI respond to full-page-zoom as you suggest, but that feels like the wrong tool for the job (even though it feels like it might be appropriate in a one-off encounter), as I've described above.

> Perhaps this needs to be reclassified rather than closed

Sure -- for now, I'll broaden the title a bit and reclassify this under our accessibility-features component; and if we end up with a plan of attack, we can further reclassify or spin off helper-bugs as appropriate.

(Also: if you feel like bits of Firefox UI like `datalist`/`calendar` are uniquely-inaccessible in Firefox and are easier to read in other browsers, that perhaps merits its own bug; & in that case, someone might also consider redesigning/scaling those components so that they're easier-to-read by default.)

(In reply to Amy C from comment #11)
> Maybe the other elements need to change, too.

That's certainly possible!
 
With that broadening, that makes this potentially-more-actionable; but I still think we'd need a plan/design of some sort before making a change here, and some confidence that the approach is coherent.

One side note here: it looks like browsers are aligned on their behavior here right now (in the sense of not-honoring full-page-zoom for these components), as far as I can tell.  (Though if I'm missing something, please do mention that here, since other browsers' tested/proven approaches might be worth exploring or using as inspiration for whatever we end up doing here.)

> it is frustrating to not be able to read a datalist, alert, date picker, etc

That's understandable.  Though it still feels inefficient/awkward to key this mitigation off of a [potentially] site-specific full-page zoom level, when the sizing itself is not site-specific.  I can see how in-the-moment a user would expect Full-Page-Zoom to work as an immediate mitigation, but it feels like it's a tool/band-aid that's not exactly right for this problem, and the persistence of full-page-zoom would create some weird results.

E.g. suppose that, due to the page's font settings, your saved full-page-zoom level for https://www.wikipedia.org/ is 300%, whereas https://qz.com/ uses larger fonts and so you use the default 100% full-page-zoom level there. Does it really make sense for the browser to interpret these differing per-site full-page-zoom levels as a user-request that these various bits of browser UI (datepickers, alerts, datalist, maybe even context menu)  to render 3x as large on Wikipedia vs. on qz.com?  That doesn't make a lot of sense to me.

If these bits of UI are too small, it feels like the right fix here is to offer the user a way to directly fix that, rather than requiring them to use full-page-zoom every time they encounter these pieces of UI (which are, after all, fully under the browser's control).

One way that is **already** available to users is the OS resolution/font settings, as noted above.

I can also imagine that Firefox could provide an "override OS settings and use this minimum font in browser UI" option in its configuration (though I can imagine that'd get tricky if the user later makes an update to their OS settings and wonders why Firefox doesn't respect that).

Alternately, we could make all of this UI respond to full-page-zoom as you suggest, but that feels like the wrong tool for the job (even though it feels like it might be appropriate in a one-off encounter), as I've described above.

> Perhaps this needs to be reclassified rather than closed

Sure -- for now, I'll broaden the title a bit and reclassify this under our accessibility-features component; and if we end up with a plan of attack, we can further reclassify or spin off helper-bugs as appropriate.

(Also: if you feel like bits of Firefox UI like `datalist`/`calendar` are uniquely-inaccessible in Firefox and are easier to read in other browsers, that perhaps merits its own bug; & in that case, someone might also consider redesigning/scaling those components so that they're easier-to-read by default.)

(In reply to Amy C from comment #11)
> Maybe the other elements need to change, too.

That's certainly possible!
 
With that broadening, that makes this potentially-more-actionable; but I still think we'd need a plan/design of some sort before making a change here, and some confidence that the approach is coherent.

One side note here: it looks like browsers are aligned on their behavior here right now (in the sense of not-honoring full-page-zoom for these components), as far as I can tell.  (Though if I'm missing something, please do mention that here, since other browsers' tested/proven approaches might be worth exploring or using as inspiration for whatever we end up doing here.)

> it is frustrating to not be able to read a datalist, alert, date picker, etc

That's understandable.  Though it still feels inefficient/awkward to key this mitigation off of a [potentially] site-specific full-page zoom level, when the sizing itself is not site-specific.  I can see how in-the-moment a user would expect Full-Page-Zoom to work as an immediate mitigation, but it feels like it's a tool/band-aid that's not exactly right for this problem, and the persistence of full-page-zoom levels would create some weird results.

E.g. suppose that, due to the page's font settings, your saved full-page-zoom level for https://www.wikipedia.org/ is 300%, whereas https://qz.com/ uses larger fonts and so you use the default 100% full-page-zoom level there. Does it really make sense for the browser to interpret these differing per-site full-page-zoom levels as a user-request that these various bits of browser UI (datepickers, alerts, datalist, maybe even context menu)  to render 3x as large on Wikipedia vs. on qz.com?  That doesn't make a lot of sense to me.

If these bits of UI are too small, it feels like the right fix here is to offer the user a way to directly fix that, rather than requiring them to use full-page-zoom every time they encounter these pieces of UI (which are, after all, fully under the browser's control).

One way that is **already** available to users is the OS resolution/font settings, as noted above.

I can also imagine that Firefox could provide an "override OS settings and use this minimum font in browser UI" option in its configuration (though I can imagine that'd get tricky if the user later makes an update to their OS settings and wonders why Firefox doesn't respect that).

Alternately, we could make all of this UI respond to full-page-zoom as you suggest, but that feels like the wrong tool for the job (even though it feels like it might be appropriate in a one-off encounter), as I've described above.

> Perhaps this needs to be reclassified rather than closed

Sure -- for now, I'll broaden the title a bit and reclassify this under our accessibility-features component; and if we end up with a plan of attack, we can further reclassify or spin off helper-bugs as appropriate.

(Also: if you feel like bits of Firefox UI like `datalist`/`calendar` are uniquely-inaccessible in Firefox and are easier to read in other browsers, that perhaps merits its own bug; & in that case, someone might also consider redesigning/scaling those components so that they're easier-to-read by default.)

(In reply to Amy C from comment #11)
> Maybe the other elements need to change, too.

That's certainly possible!
 
With that broadening, that makes this potentially-more-actionable; but I still think we'd need a plan/design of some sort before making a change here, and some confidence that the approach is coherent.

One side note here: it looks like browsers are aligned on their behavior here right now (in the sense of not-honoring full-page-zoom for these components), as far as I can tell.  (Though if I'm missing something, please do mention that here, since other browsers' tested/proven approaches might be worth exploring or using as inspiration for whatever we end up doing here.)

> it is frustrating to not be able to read a datalist, alert, date picker, etc

That's understandable.  Though it still feels inefficient/awkward to key this mitigation off of a [potentially] site-specific full-page zoom level, when the sizing itself is not site-specific.  I can see how in-the-moment a user would expect Full-Page-Zoom to work as an immediate mitigation, but it feels like it's a tool/band-aid that's not exactly right for this problem, and the persistence of full-page-zoom levels would create some weird results.

E.g. suppose that, due to the page's font settings, your saved full-page-zoom level for https://www.wikipedia.org/ is 300%, whereas https://qz.com/ uses larger fonts and so you use the default 100% full-page-zoom level there. Does it really make sense for the browser to interpret these differing per-site full-page-zoom levels as a user-request that these various bits of browser UI (datepickers, alerts, datalist, maybe even context menu)  to render 3x as large on Wikipedia vs. on qz.com?  That doesn't make a lot of sense to me.

If these bits of UI are too small, it feels like the right fix here is to offer the user a way to directly fix that, rather than requiring them to use full-page-zoom every time they encounter these pieces of UI (whose sizing is fully under the browser's control).

One way that is **already** available to users is the OS resolution/font settings, as noted above.

I can also imagine that Firefox could provide an "override OS settings and use this minimum font in browser UI" option in its configuration (though I can imagine that'd get tricky if the user later makes an update to their OS settings and wonders why Firefox doesn't respect that).

Alternately, we could make all of this UI respond to full-page-zoom as you suggest, but that feels like the wrong tool for the job (even though it feels like it might be appropriate in a one-off encounter), as I've described above.

> Perhaps this needs to be reclassified rather than closed

Sure -- for now, I'll broaden the title a bit and reclassify this under our accessibility-features component; and if we end up with a plan of attack, we can further reclassify or spin off helper-bugs as appropriate.

(Also: if you feel like bits of Firefox UI like `datalist`/`calendar` are uniquely-inaccessible in Firefox and are easier to read in other browsers, that perhaps merits its own bug; & in that case, someone might also consider redesigning/scaling those components so that they're easier-to-read by default.)