Bugzilla

(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 prefer 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.

(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.