Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #35811 > unrolled thread

Lang attribute on html element

Back to article view | Back to comp.lang.javascript

Contents

  Lang attribute on html element Andrew Poulos <ap_prog@hotmail.com> - 2018-11-13 14:50 +1100
    Re: Lang attribute on html element Andrew Poulos <ap_prog@hotmail.com> - 2018-11-13 16:09 +1100
      Re: Lang attribute on html element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-11-13 22:40 +0100
        Re: Lang attribute on html element Andrew Poulos <ap_prog@hotmail.com> - 2018-11-14 10:00 +1100

#35811 — Lang attribute on html element

I have a page that onload runs some JavaScript that sets a value for 
lang on the html element.

What concerns me is that if this is "too late" for screen readers to 
correctly interpret the page's language. That is, does the appropriate 
lang attribute need to be hard coded in the page for screen readers to 
recognise it?

Would using DOMContentLoaded be safer?

Andrew Poulos

[toc] | [next] | [standalone]

#35812

On 13/11/2018 2:50 pm, Andrew Poulos wrote:
> I have a page that onload runs some JavaScript that sets a value for 
> lang on the html element.
> 
> What concerns me is that if this is "too late" for screen readers to 
> correctly interpret the page's language. That is, does the appropriate 
> lang attribute need to be hard coded in the page for screen readers to 
> recognise it?
> 
> Would using DOMContentLoaded be safer?

After some testing, using DOMContentLoaded triggers Chrome to ask if I 
want the page translated so maybe it will also be picked up by screen 
readers.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#35813

Andrew Poulos wrote:
> On 13/11/2018 2:50 pm, Andrew Poulos wrote:
>> I have a page that onload runs some JavaScript that sets a value for 
>> lang on the html element.
>>
>> What concerns me is that if this is "too late" for screen readers to 
>> correctly interpret the page's language. That is, does the appropriate 
>> lang attribute need to be hard coded in the page for screen readers to 
>> recognise it?
>>
>> Would using DOMContentLoaded be safer?
> 
> After some testing, using DOMContentLoaded triggers Chrome to ask if I 
> want the page translated so maybe it will also be picked up by screen 
> readers.

Your argument is based on the assumption that all user agents with which
screen readers can be used also execute client-side scripting (in a
DOM-compatible way).  This assumption is false: a prominent counter-example
is Lynx.

Therefore, too, always generate the initial “lang” attribute value
*server-side*.


PointedEars
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#35814

On 14/11/2018 8:40 am, Thomas 'PointedEars' Lahn wrote:
> Andrew Poulos wrote:
>> On 13/11/2018 2:50 pm, Andrew Poulos wrote:
>>> I have a page that onload runs some JavaScript that sets a value for
>>> lang on the html element.
>>>
>>> What concerns me is that if this is "too late" for screen readers to
>>> correctly interpret the page's language. That is, does the appropriate
>>> lang attribute need to be hard coded in the page for screen readers to
>>> recognise it?
>>>
>>> Would using DOMContentLoaded be safer?
>>
>> After some testing, using DOMContentLoaded triggers Chrome to ask if I
>> want the page translated so maybe it will also be picked up by screen
>> readers.
> 
> Your argument is based on the assumption that all user agents with which
> screen readers can be used also execute client-side scripting (in a
> DOM-compatible way).  This assumption is false: a prominent counter-example
> is Lynx.

I'm creating some elearning which will run off a Learning Management 
System (LMS). The LMS always needs JavaScript to be available for it to 
serve and track elearning.

> Therefore, too, always generate the initial “lang” attribute value
> *server-side*.

That is probably the better way to do it.

Andrew Poulos

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web