Users need a way to increase the size of overlays/menus that come from web content but are styled as browser UI (e.g. datetime-picker, text-input datalist, alert(), prompt(), tooltip)
Categories
(Firefox :: Disability Access, defect, P3)
Tracking
()
| Accessibility Severity | s2 |
People
(Reporter: click2carney, Unassigned)
References
Details
(Keywords: access)
Attachments
(3 files, 1 obsolete file)
tooltip from a title, a datepicker from input type=date, browser UI is visibly smaller than the content while browser zoom is set to 200%
| Comment hidden (obsolete) |
Sorry about the weird markup! I missed a tick and now it's hard to read. Since I can't edit my message, I'm replying for easier readability.
Steps to reproduce:
I created a datalist inside a form, like the following example:
<input type="text" list="list">
<datalist id="list">
<option>Option 1</option>
<option>Option 2</option>
<option>Option 3</option>
<option>Option 4</option>
</datalist>
Actual results:
The datalist was created, as expected, but the list of options that appear don't scale when the browser zoom is increased, or text-only zoom is used. The font size remains at the browser default. This deviates from how select options work, which do scale with zoom.
Expected results:
If a user zoom's in 200%, the datalist font size should get bigger (enlarge along with surrounding text). I tried to style the datalist and options to improve this, but those styles didn't work.
This is a huge accessibility issue (fail) for people who have a visual disability or need to zoom in for other reasons. The browser should automatically scale the box and list alongside the rest of the content.
|
||
Comment 2•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout: Form Controls' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Updated•3 years ago
|
|
|
||
Comment 3•3 years ago
•
|
||
Thanks for the bug report! Here's a testcase.
You brought up input-with-datalist vs. select, and your perception was that input-with-datalist is specially broken -- but really, there are a handful of other relevant comparable elements and categories of popup-UI -- and really, select is the special one in that it does scale, rather than input-with-datalist being special in not-scaling.
And there's a good reason that the select dropdown does scale with full-page-zoom-level -- it's not directly for accessibility purposes, but rather because the whole select element and its options are stylable as part of the web page, and are exposed to the web developer for styling, so their sizes are inherently tied to the rest of the web page. e.g. the web developer might set a particular font and font-size on an option, and they'd rightly expect for that font/font-size to render the same whether it's on an option vs. some other piece of content. See for example my second select dropdown in this testcase -- it has font-size:200% on one of the options, which needs to render 2x as big as the others and 2x as big as the surrounding text, regardless of the full-page-zoom level.
In contrast, the textfield dropdown element (as well as all the other popups shown in my attached testcase, and e.g. the right-click context menu) is not stylable by the web page, and does not grow with full-page-zoom -- these other popups are just "native" pieces of the browser UI. Given that they render the same everywhere, it would be a bit odd for them to respond to full-page zoom. It would also be bad for accessibility if someone needed to zoom out in order to see a web page's content, and these bits of UI got smaller & inaccessible as part of that zoom-out operation.
I think the user-facing solution here is to allow users to establish a minimum desired size for the text in these bits of "browser-native" UI, like text dropdowns. I suspect/hope there is a way to do that, independent of full-page-zoom... let me ask around and find out. If not, then that's probably what this bug should really track.
|
|
||
Updated•3 years ago
|
|
|
||
Comment 4•3 years ago
•
|
||
On Windows and Linux at least, there are OS-level settings that let you customize applications' default fonts and font-sizes, which I'm told will influence the size of text in Firefox's UI (including the textfields' dropdown-menu for e.g. datalist).
It looks like you're on macOS, though, based on this bug's Platform field -- I don't think macOS provides that exact default-font-customization UI, but they do let you customize your resolution under the "Displays" section of their Preferences app. (Resolution: Scaled, and then you can pick one of the options closer to "Larger Text" -- this UI might also be different depending on your display & OS version, too.)
Does that macOS setting (picking a "larger text" option there) address your use-case?
If not, can you say more about why these textfield-dropdown-menus in particular are too small, given that they are (I think) the same size as other text in the browser's UI and other platform native UI? (I want to be sure we understand your use case & issue and be sure that the benefit-vs-complexity tradeoff makes sense for any solution we end up morphing this bug into here.)
|
||
Updated•3 years ago
|
|
|
||
Comment 5•3 years ago
•
|
||
A few additional thoughts/points that might clarify things here...
(Kind of restating what I've said already, but perhaps in a clearer / more-structured way.)
(1) Clearly Firefox itself (the application itself, menus, location bar, etc.) needs to have sufficiently-large-text to be readable to the user. Firefox defers to the system-defaultsfor text sizing here, I think; and the recommended way to customize its UI-text-size is to use the OS-specific system configuration tools to adjust resolution/application-text. (If those aren't sufficient for this purpose, then that'd be a legitimate issue that deserves its own bug.)
(2) Web content that is stylable by web developers is in a different category and needs further intervention -- it cannot necessarily be assumed to respect the user's chosen defaults, since web developers might e.g. specify too small of a font on a particular element, or make another inadvertently-bad design choice. Full-Page Zoom is one way of addressing this.
(3) <select> dropdown menus fit into that second category -- the web developer has control over the font & font-size used in the option elements there, so they might be unreadably-small due to unfortunate choices on the part of the web developer. So, full-page-zoom applies to these dropdown menus, in order to give the user a tool to intervene and mitigate one-off web developer design choices.
(4) However, the other sorts of dropdowns/popups that I demonstrate in testcase 1 (including but not limited to input datalist-dropdowns) are simply part of the browser's own UI, and are outside the control of web developers and are the same size regardless of the website or of web developer choices. In other words, they're in the first category that I described above in point (1). I don't think it makes sense for full-page-zoom to apply to them -- if any of these pieces of UI have text that is too small, then that's either an indication that Firefox is failing to follow the user's preferences as expressed in the system settings, or it's an indication that the system settings need to be adjusted to match the user's preferences. In either case, I'd argue that broadening the applicability of full-page-zoom would not be a robust fix, since full-page-zoom is a website-specific intervention, and the styling/sizing of these popups is not website-specific. I'd think the best way to address this would be to do so at the root, i.e. to to fix things (either at a system level or in Firefox, depending on the specifics) so that the relevant piece of Firefox's own UI is actually large enough for the user to read.
Does this explanation make sense? And given the above, do you think there's actually a bug that needs fixing here, or is this just a case where you noticed the <input>-with-datalist dropdown behaving differently from <select> and thought that was unexpected?
(As one "maybe-there's-no-bug" signal: on my system at least, the input-datalist dropdown text looks like it's the same size as the URLbar and tab-title text. If the input-datalist dropdown text is unreadably small, then I would expect the URLbar and tab-title text to be unreadably small as well; and conversely, if users configure their system such that Firefox's tabs & URL bar are readable, then I would expect this would result in their input-datalist-dropdown text being readable as well.)
|
|
||
Comment 6•3 years ago
|
||
The severity field for this bug is set to S3. However, the accessibility severity is higher, [access-s2].
:emilio, could you consider increasing the severity?
For more information, please visit auto_nag documentation.
|
|
||
Comment 7•3 years ago
•
|
||
I think my reasoning in comment 4 - comment 5 suggests that this should perhaps not be [access-s2], and should probably be closed as not-actually-a-bug.
Summarizing: this bug was filed due to an apparent-inconsistency between different types of dropdowns (<select> dropdowns honor the full-page-zoom, while text-<input> autocomplete / datalist dropdowns do not); and to the reporter, this looked like an oversight.
But in fact: <select>-dropdowns are special (maybe unique?) among "browser overlay UI" in responding to full-page-zoom, because web developers can style their contents, which means there's no guarantee that they honor the users' sizing preferences (as expressed via OS defaults); so we need to make them respond to full-page-zoom to give users a way to counteract individual pages' poor design choices.
In contrast, other dropdowns' contents should always use text that matches the OS defaults and that's the same size as all of our other frontend UI (menus/tab-titles/etc). The correct way to make all of that UI easier to read is through configuring the operating system's resolution and font preferences (or using other accessibility tools like screen-magnifiers, as-desired), not through one-off full-page-zoom adjustments.
I'm not sure I'm understanding the argument you are making here? If the user zooms in on the web page (using either page zoom or text-only zoom) then shouldn't all of the content on the web page increase in size? Isn't this giving the user control over how they view the content? Both <input> and <select> respect the user's zoom preferences, so why shouldn't <datalist>? I don't see how this has anything to do with OS defaults, as we are dealing with the browser here and users have the ability to modify the properties of the browser independently of their OS.
To be truly accessible, the <datalist> options font size should be able to scale as the user zooms in on the page. That's a AA WCAG requirement (1.4.4). If the <datalist> can't do this then it is basically unusable.
|
|
||
Comment 9•3 years ago
•
|
||
(In reply to Bruce from comment #8)
I'm not sure I'm understanding the argument you are making here?
Sure, let me try to clarify.
Essentially: if the datalist dropdown is too small, then that's certainly bad, but in that case, that's a problem that affects every datalist/autocomplete dropdown everywhere for this user -- and presumably it also affects Firefox's tab-titles, and hamburger menu, and context-menu, and all sorts of other UI which uses the same size text. (And probably affects all the same/similar bits of UI in other browsers/applications?) To the extent that this is a problem, we should absolutely be sure there are good tools in place to fix it.
And I'm saying that full-page-zoom is not a great tool to fix it, because (a) it would only fix it on a one-off manner (it would only help with this one piece of UI and only on sites where it's configured), (b) the datalist dropdown text sizing is unrelated to the text size of the rest of the webpage so it may or may not look sensible to have it scaled.
One tool that is available for this is the OS text and/or resolution settings. That may not be the best tool, but it is one place where a user can express their preferences about how big they prefer application-text to be.
If the user zooms in on the web page (using either page zoom or text-only zoom) then shouldn't all of the content on the web page increase in size?
(The datalist dropdown isn't "content on the web page"; it's rather a browser-UI-presentation of some text that is provided by the web page, which is sized according to browser/OS conventions and fully outside of the web page's control; similar to the context-menu, alert() and prompt(), for example.)
|
|
||
Comment 10•3 years ago
•
|
||
As an example of why the proposed solution (of making datalist respond to full-page-zoom) might have some bad/unwanted outcomes... here's a testcase with some (admittedly-severe) too-small and too-large web content, with a select-dropdown and a textfield-with-a-datalist in each section.
As you can see, the select dropdown is styled with the rest of the page and is too-small / too-large (which full-page-zoom mitigates), but the datalist is always "regular size", independent of the page's own styling.
Consider:
- In this example, would you really want the regular-size datalist to get bigger in the first section if the user zooms in to make that section readable?
- Perhaps more importantly, would you really want it to get smaller (potentially unusably-smaller) if the user zoomed out to make that section readable / to make it fit on-screen?
|
Reporter | |
Comment 11•3 years ago
|
||
Maybe the other elements need to change, too. As a low vision user (who happens to be a web developer and accessibility consultant), it is frustrating to not be able to read a datalist, alert, date picker, etc. When I am in the browser. I expect all the things inside the browser to scale alongside each other.
Perhaps this needs to be reclassified rather than closed? WCAG 1.4.4 - Resize Text clarifies that the user agent is primarily responsible for allowing the user to scale content. I understand what you are trying to convey about the OS. But many users who needs zoom in the browser expect all things inside the browser to scale together, no matter what their OS is doing.
|
|
Reporter | |
Comment 12•3 years ago
|
||
To clarify my submission here, as web developer working on a datalist recently, it came to my attention that I struggled reading the datalist I was creating when all elements around it were larger. Then realized I couldn't even style it to make it scale with the rest of the content.
Apologies if my intent wasn't clear enough.
|
|
||
Comment 13•3 years ago
•
|
||
(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.)
|
||
Comment 14•3 years ago
|
||
For what it's worth, I think approaching this like contextual menus available on right click is, forgive the pun, lacking Vision.
The thing is, if it's loaded as part of the web page, it ought to resize in the same way other element of a web page resize. Simple as that. Don't put onus on the user to make sure their OS settings are right. Don't make them think.
What if someone uses 300% on one page, and 100% on another page? That's a non-issue.
The issue is that datalist, and other elements that are loaded in a page should scale relative to the rest of the page, when a user needs/requires it.
|
|
||
Comment 15•3 years ago
•
|
||
(In reply to Nic Steenhout from comment #14)
For what it's worth, I think approaching this like contextual menus available on right click is, forgive the pun, lacking Vision.
Sure -- I used that since it was the first other browser-provided "menu/overlay" that appears over web content (with the same sized text as the datalist) that I could think of. But I admit that one's a bit of a stretch (users aren't likely to consider context-menus to be full-page-zoomable), so let's just disregard that and focus on the other examples where the overlay's content clearly comes from the web developer but the presentation/styling/sizing comes from the browser (and all of these happen to ignore full-page-zoom in all browsers I think):
- the
<input type="text">datalist dropdown - the
titlei.e. tooltip attribute (I just thought of that one). E.g. in this data-URI testcase (loadable by copypasting this into your URL bar and hitting enter)
data:text/html,<div title="I am a tooltip">Hover me to show tooltip - the
<input type="datetime">dropdown/picker - JS
alert()/prompt()popups - maybe others we haven't thought of yet.
Don't put onus on the user to make sure their OS settings are right. Don't make them think.
To be clear, I'm not saying "when a user encounters a too-small datalist, they should go in and reconfigure their OS settings".
I was saying that all of the UI in the above list is (or should be) styled to be as big as other important pieces of browser frontend UI (e.g. menus, tab-titles, the URL bar itself) which the user quite-rightly should expect to be able to read. If that text is all too small, then that's a bigger problem that I'd imagine we'd want to help users fix across the board, rather than just providing a band-aid for one tiny piece of UI. (And OS settings is one existing way to fix that, which a user might reach for when using Firefox or any-application-at-all for the first time and noticing the UI text is too small; though maybe we need something in Firefox preferences as well? I'm not sure.)
datalist, and other elements that are loaded in a page should scale relative to the rest of the page, when a user needs/requires it.
That's one option here, but as my testcase 2 shows, that's a bit awkward because the default sizes of these things are unrelated to the (web-developer-specified) default sizes of the various content in the rest of the page. So if the rest of the page is small and the datalist is default-sized, then the datalist may get awkwardly large when the user scales to be able to read the rest of the page. Maybe that's fine? But it's a bit of a strange wart, at least.
|
|
||
Comment 16•3 years ago
•
|
||
I think I'm mostly-done expressing my own opinions for now (hopefully I've made my concerns/thoughts/edge-cases-to-consider fairly clear), and I'm curious to hear what thoughts mozilla's a11y folks & frontend designers might have on this.
Also: given that the current behavior seems to be interoperable across all browsers, it feels like maybe the resulting proposal here might be something that we'd need/want to discuss with other browsers in a standards-body and get feedback from other browsers & standardize on a solution for this.
(And if the standardized behavior ends up being "yes, just please treat all of this content as part-of-the-web-page and scale it with full-page zoom" which seems to be the request here, then so be it & we can go from there. Or if the outcome is "Browsers should provide users with an option to configure minimum-font-size-for-browser-UI including UI that shows up in-content" or something else completely different, then we can go from there. But it would be not-great to end up with "full-page zoom" being a feature that scales different and potentially non-overlapping sets of things in different browsers, and I want to avoid inadvertently ending up there, if we and other browsers were to address this sort of issue in different patchwork-style ways.)
|
|
Reporter | |
Comment 17•3 years ago
|
||
Agreed it's a cross-browser. A Chromium bug was already submitted, that I fully support.
Thanks for mentioning the title attribute. A bane to my existence! I have always struggled with that one, and hated how it has been inaccessible to me (can't enlarge, blocked by my large mouse cursor due to position). I'd love to see some real change there, too.
I can't even conceive what browser creation/maintenance involves. That's not my wheelhouse. But I do feel like I have just accepted some things as they were/are since I got on the internet in the mid-90s. It's probably a good time to revisit this implementations and acknowledge we have the capability to improve them in 2022.
Thanks, again, for keeping the conversation going and being willing to listen, learn, and find the right solution.
|
|
||
Updated•3 years ago
|
|
||
Comment 18•3 years ago
•
|
||
hi folks! thanks for all this discussion :) it sounds like there are a few different issues at play here:
- On a given page, it isn't immediately obvious which content is considered web content and which content is considered browser UI. And because of that it isn't clear which things should respond to zoom, and which shouldn't (to take that one step further, perhaps: it isn't clear that FF intends to only apply zoom to web content, and not browser UI). While the "browser content" vs. "web content" distinction may be more apparent from an engineering point of view, it seems that distinction isn't carried over to our general UX. This messes with user expectations and leads to a frustrating experience overall. We have this issue when discussing the behaviour of our
about:pages vs. the behaviour of "regular" web content, too. For example, tooltips on ourabout:pages respond to page zoom, but tooltips on "regular" web content do not. - There exists a need to customise font size on an application-by-application basis. While (it appears) most major web browsers have similar initial font sizes, there are slight differences which may be enough for a user to need to adjust font size for a single app in particular. Users may also need individual apps to have different font sizes based on situational usage. For example, if you only use an app for a few minutes a day its default font size may be fine, but if you use an app for multiple hours a day you may need a larger font size to help avoid eye strain. The colors an app uses to render text may also impact the usable font size. Using an OS-setting alone doesn't help here.
- Ease of access. Apart from the expectations discussed in (1), page zoom is a simple, prominent, semi-universal way to adjust content size. It is exposed on every web page and isn't buried somewhere in about:preferences. This doesn't necessarily mean that page zoom should be the fix here, but I think it's something worth pointing out when we're considering alternative solutions.
- Users on macOS don't have a font scaling OS setting to help here. While windows and (I believe) linux offer specific font-scaling settings in their OS settings, macOS doesn't. Apple does expose a resolution scaling setting, but this adjusts far more than font size, and have unintended consequences. It's a rather "kitchen sink" approach to making a datalist more visible 😀
Please let me know if I've incorrectly portrayed any of the above issues.
My thoughts:
I think this is a valid bug. I also think page zoom is not the way to solve this issue.
I see two possible ways forward here:
- Expose a UI scaling option somewhere (preferences, or about:config)
- Expose a UI font-scaling option somewhere (")
Based on the bug reports we've gotten related to this issue (the tooltips one comes to mind, but I believe there were others when I was working on the default-zoom stuff), I think the font-scaling option might be the place to start.
We could consider exposing this as a checkbox in our existing font settings (about:preferences > Language and Appearance > Fonts). Something like "Apply my preferred font size to UI and web content" might be helpful? We could also nest this in the "Advanced" fonts section, near "Minimum font size", though in line with (3) above I think that might be too obscured.
Re: how do we reconcile our setting with any OS-setting for font scaling, we could do something like what we do with the web appearance chooser when FF-HCM is enabled: expose a warning to the effect of "your other settings may conflict with this setting, so behaviour is undefined".
I'll need to look into OS-font-scaling detection, but there's probably a system registry value to check somewhere. That's how we check if OS-HCM is enabled, right now.
I'm interested in a frontend perspective on this -- :gijs do you have thoughts? 😀
|
||
Comment 19•3 years ago
|
||
"I also think page zoom is not the way to solve this issue."
But this is the primary issue this bug was created for. As the user zooms in on the page and the zoom percentage increases, the text size should increase as well. This is a WCAG requirement. Technically, one might consider the datalist content to be browser UI, but in order to use it as a proper functional component on a web page then it needs to be considered web content that can resize as the user zooms in.
|
|
||
Comment 20•3 years ago
•
|
||
(In reply to Bruce from comment #19)
"I also think page zoom is not the way to solve this issue."
But this is the primary issue this bug was created for. As the user zooms in on the page and the zoom percentage increases, the text size should increase as well. This is a WCAG requirement. Technically, one might consider the datalist content to be browser UI, but in order to use it as a proper functional component on a web page then it needs to be considered web content that can resize as the user zooms in.
The WCAG requirement is:
Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.
This UI currently responds to resizing initiated by OS settings -- font scaling and resolution scaling do resize data lists. These settings do not require assistive technology (ie. magnifier apps).
The fact that page zoom does not do this is not a violation because, as Daniel mentions, that is not the intended use of this feature. It is frustrating that this isn't well communicated (or documented). Page zoom is intended to give users control over scaling issues caused by web authors. Like I said above, we should also give users control over scaling issues caused by Firefox 😀 but merging those features into one might not be best for everyone.
Consider the following:
data:text/html,<p id="p1" style="font-size:9px;">hello world I am some annoyingly small, inaccessible text</p><input type="text" list="list"><datalist id="list"><option>Option 1</option><option>Option 2</option><option>Option 3</option><option>Option 4</option></datalist>
In this example, a user might use page-zoom to increase the size of the p1 content. If we also scaled the content of the data list, the options drop down might become disruptively large, or obscure too much web content. Separating these settings ensures that users who only intend to scale page content have that ability, and that users who need to scale both page content and browser UI can do that too.
Another way forward here is to add a "Zoom in-content browser components" checkbox under our zoom section, similar to the "Zoom text only" option we currently offer.
|
|
||
Comment 21•3 years ago
|
||
re: implementation
:dholbert, where do we render components like the datalist, and other non-zoomable but possibly in-content UI? does that still happen in the content process?
|
||
Comment 22•3 years ago
|
||
Honestly honoring zoom in at least tooltips and datalists seems sensible enough. They are part of the content area after all, and as you mentioned they get scaled in internal pages... We propagate tooltip CSS directionality for example.
For tooltips it's this code. For autocomplete (which covers datalist) it's this code.
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
|
||
Comment 23•3 years ago
|
||
"that is not the intended use of this feature"
I think this is where we have a disconnect. From my perspective, it is a web component just like a <select> is a web component. I'm not sure why it should be treated differently?
"Page zoom is intended to give users control over scaling issues caused by web authors.:"
I think your view here is a little too narrow. Yes, some authors might create text that is too small, but just as likely, the text size is perfectly reasonable for the average user, it's just that a lot of people need a bigger text size because their vision is not as good as the average user. This has nothing to do with scaling issues caused by the author. Some people just need bigger text size. Zoom is one of the primary tools people can use to get a bigger text size. This is how you meet the WCAG requirement that "text can be resized without assistive technology up to 200 percent."
|
|
||
Updated•3 years ago
|
|
|
||
Comment 24•3 years ago
|
||
I don't plan on finishing this up (too late today now anyways). Would
need tests and so on.
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
||
Comment 25•3 years ago
|
||
I don't think I have much to add here. I think it's not clear-cut what we should be doing. A "middle way" would be sizing content using the default zoom factor, instead of the per-site zoom factor, given that the current sizes of alerts/tooltips/datalists are the same cross-site, and any scaling should be cross-site rather than site-specific. The counterargument is that the shortcuts and other UI affordances while the page is open all relate to the per-site zoom, not the default zoom.
I am unenthusiastic, in terms of cost/benefit (esp. considering cost in terms of user confusion) about adding a separate control for Firefox-UI-font-size independent from the OS settings. (though layout.css.devPixelsPerPx is already a working klutch-y substitute for that)
I would be stunned if you could do whatever we end up settling on without some people Being Upset. In the site-specific case they will be upset that Weird Site X that they zoom in because the font is tiny, now has giant tooltips, and other site that they don't zoom in has normal tooltips - all tooltips should be the same, they are Firefox UI! If we do nothing, people will be upset about that (viz. the existing comments). If we add another, separate setting, people will be upset that it doesn't "just" obey page zoom (idem).
|
|
||
Comment 26•3 years ago
|
||
Well, for starter, I really loathe thinking of accessibility in terms of "cost/benefit". You're not looking at a "nice to have" feature. You're looking at actually excluding people. Which I'm sure isn't what you want to do, but that's how comments like this sound like to those of us with disabilities who are so often excluded.
But how about this: If you're really not going to manage to make everyone happy, why not make it accessible? Then a whole bunch of people who could not otherwise actually use the page, will be able to use it. As opposed to not only being "unhappy", but actually unable to use it.
|
|
||
Comment 27•3 years ago
|
||
(In reply to Nic Steenhout from comment #26)
Well, for starter, I really loathe thinking of accessibility in terms of "cost/benefit". You're not looking at a "nice to have" feature. You're looking at actually excluding people. Which I'm sure isn't what you want to do, but that's how comments like this sound like to those of us with disabilities who are so often excluded.
I was explicit that I was talking about cost to other users, so you are misrepresenting what I said. I'm also confused because I mentioned this in relation to a solution you yourself have been arguing against (ie not dealing with this using page zoom, but requiring users to find and use some other preference, independent of page zoom).
But how about this: If you're really not going to manage to make everyone happy, why not make it accessible? Then a whole bunch of people who could not otherwise actually use the page, will be able to use it. As opposed to not only being "unhappy", but actually unable to use it.
How about you stop imputing bad motives and dismissing other users' needs based on the particulars of my phrasing, which is is disingenuous and won't help getting to a solution here.
We're trying to find a solution which is intuitive, matches users' expectations, and addresses various users' needs. That is not straightforward, or there wouldn't be 2 dozen comments about it already. Attempts to claim that it is trivial aren't going to help getting to that solution, so please stop.
|
|
||
Comment 28•3 years ago
|
||
I'm very sorry I came through as disingenuous and misrepresenting what you said. FWIW, I wasn't imputing bad motives to you.
I'll readily admit to having strong reactions when I see the expression "cost/benefit" attached to accessibility. I do not have the Privilege of not knowing what it's like to live with a disability and encountering lack of accessibility in my day to day life. I don't have the luxury of not being faced with literally dozens of micro-aggressions every day.
So sure, you could read my reaction as an over reaction. It is more of a "I'm-thoroughly-fed-up-with-having-to-justify-acccessibility-needs-all-the-time".
I'll step away from this discussion, as I don't want more folks to think I attribute ill intent to them when it's not the case. I'll be happy to answer any specific and direct question for me if there are any, but in general, I have nothing more to add to this conversation.
|
|
||
Updated•3 years ago
|
|
||
Comment 32•3 years ago
|
||
The bug summary only mentions tooltip text size, but bug 1793793, and comment 17 here, both concern tooltip position; currently the tooltip appears directly behind the cursor.
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
||
Comment 33•7 months ago
•
|
||
This bug also applies to other platforms besides macOS. Screenshot of a title text and Fx datepicker while the browser zoom is set to 200% to follow
|
|
||
Comment 34•7 months ago
|
||