3 回答
TA贡献1775条经验 获得超11个赞
退后一步!首先,您假设用户在设备上使用的是外部语言环境,这不是合理的假设,可以证明接管文件选择器的按钮文本并使其说出您想要的内容。
您希望控制页面上可见的每一项语言都是合理的。但是,“文件上载”控件的内容不是HTML的一部分。该控件后面有更多内容,例如,在WebKit中,该按钮旁边还显示“未选择文件”。
有很多骇人的解决方法可以尝试此操作(例如,就像@ChristopheD的答案中提到的那样),但没有一个能真正成功:
对于屏幕阅读器,文件控件仍将显示“浏览...”或“选择文件”,自定义文件上载不会被宣布为文件上载控件,而仅是按钮或文本输入。
他们中的许多人无法显示所选文件,或表明用户不再选择文件
它们中的许多看起来都不像本机控件,因此在非标准设备上可能看起来很奇怪。
键盘支持通常很差。
作者创建的UI组件永远无法像其本机同等功能那样发挥全部功能(并且越接近于Windows 7上假设IE10的行为,它与其他浏览器和操作系统组合的偏差就越大)。
现代浏览器支持拖放到本地文件上传控件中。
作为潜在的“点击劫持”尝试,诱使用户上传文件,某些技术可能会触发安全软件中的启发式方法。
偏离本机控件始终是一件危险的事情,您的用户可能会使用大量不同的设备,无论选择哪种解决方法,您都不会在所有这些设备中都进行过测试。
但是,从用户体验的角度来看,所有尝试失败的原因还有一个更大的原因:该控件(文件选择对话框本身)背后还有更多非本地化的内容。一旦用户经历了其文件系统的遍历或不选择要上传的文件的内容,他们将受到主机操作系统语言环境的约束。
您确定要通过偏离本机控件来使用户无可厚非,只是为了对文本进行本地化,当他们单击文本时,他们无论如何都将获得操作系统的区域设置?
您可以为用户做的最好的事情就是确保围绕文件输入控件具有足够的本地化指导。(例如,表单字段标签,提示文本,工具提示文本)。
抱歉。:-(
-
该答案适用于那些寻求任何理由不对文件上载控件进行本地化的人。
- 3 回答
- 0 关注
- 319 浏览
添加回答
举报