搜索 | 用户支持

防范以用户支持为名的诈骗。我们绝对不会要求您拨打电话或发送短信,及提供任何个人信息。请使用“举报滥用”选项报告涉及违规的行为。

详细了解

When an element receives focus, the header of the website is hiding the lement since the browser is not scrolling wnough to make the element visible

more options

Well, the whole issue came when I am testing an application for accessibility. There's a page which is a typical registration form, which has two columns. The left column had text fields for personal details, whereas the right column has some radio buttons, and text fields about username etc. When I am accessing the form using only 'tab' (without using mouse), the cursor starts with the first field in the left column and then to the field below that. Once all the fields in the left column are completed, it goes to the first field in the right column. While tabbing in the left column, after around 5 fields, the browser starts scrolling down to make the focused element visible in the viewport, which is the expected behavior. From the last field of the left column, when I tab, it goes to the first field in the right column. The browser scrolls up but the focused element is not visible in the viewport. I tried using the keyboard arrow keys but since the focus is in either text field or radio button (in two different scenarios), the use of arrow keys is showing the input suggestions for text fields(suggestions from previous inputs) and changing the radio button checked value for radio groups. Hence, the focused element is not visible in the viewport but we can enter data or change the values, which is a defect. In my research of finding the root cause what I found is - There's a header in our application which has links to menu and profile etc. When tabbed from last field from the left column to the first field in the right column, the browser scrolls up but the header strip is hiding the field. When I remove the header using firebug and check, the field is perfectly visible. But when the header is present it is hiding it. Ideally, the browser should sense the presence of header and scroll enough to make the field visible. Chrome is working this way. Though the header is present, it is scrolling enough to make the field visible. But Firefox is not behaving like this. I observed similar behavior this support page where I am posting the question. I will add the document containing the screenshots. But, the support page had links, so even though the browser is not scrolling automatically, we can scroll using arrows. But, it should scroll automatically because not always we will have links, the browser should be able to work for the form fields as well.

To summarize, Firefox should sense the presence of any headers in an application and scroll accordingly, when tabbed, to make sure every field is visible and also not rely on the usage of arrow keys because text fields, radio buttons, check boxes, combo boxes have different functionalities for the arrow keys.

Well, the whole issue came when I am testing an application for accessibility. There's a page which is a typical registration form, which has two columns. The left column had text fields for personal details, whereas the right column has some radio buttons, and text fields about username etc. When I am accessing the form using only 'tab' (without using mouse), the cursor starts with the first field in the left column and then to the field below that. Once all the fields in the left column are completed, it goes to the first field in the right column. While tabbing in the left column, after around 5 fields, the browser starts scrolling down to make the focused element visible in the viewport, which is the expected behavior. From the last field of the left column, when I tab, it goes to the first field in the right column. The browser scrolls up but the focused element is not visible in the viewport. I tried using the keyboard arrow keys but since the focus is in either text field or radio button (in two different scenarios), the use of arrow keys is showing the input suggestions for text fields(suggestions from previous inputs) and changing the radio button checked value for radio groups. Hence, the focused element is not visible in the viewport but we can enter data or change the values, which is a defect. In my research of finding the root cause what I found is - There's a header in our application which has links to menu and profile etc. When tabbed from last field from the left column to the first field in the right column, the browser scrolls up but the header strip is hiding the field. When I remove the header using firebug and check, the field is perfectly visible. But when the header is present it is hiding it. Ideally, the browser should sense the presence of header and scroll enough to make the field visible. Chrome is working this way. Though the header is present, it is scrolling enough to make the field visible. But Firefox is not behaving like this. I observed similar behavior this support page where I am posting the question. I will add the document containing the screenshots. But, the support page had links, so even though the browser is not scrolling automatically, we can scroll using arrows. But, it should scroll automatically because not always we will have links, the browser should be able to work for the form fields as well. To summarize, Firefox should sense the presence of any headers in an application and scroll accordingly, when tabbed, to make sure every field is visible and also not rely on the usage of arrow keys because text fields, radio buttons, check boxes, combo boxes have different functionalities for the arrow keys.

所有回复 (2)

more options

Hi

For web development and programming support, I recommend that you ask in Stack Overflow. The experts there should be able to help with this issue.

I also recommend that you update your copy of Firefox to make sure that you have recent security and stability fixes, as well as new features. You can read more about how to update here.

more options

Hi,

As I explained, I don't think it's a problem with development or programming. Any how, I'll post it there since you suggested.

My Firefox is up to date.

Well, the scenario I explained works perfectly in Chrome. It is not advisable to manipulate the code to scroll to a specific point. It might cause other defects or inconsistent behavior.