From Newsgroup: comp.lang.javascript

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
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.javascript

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

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.javascript

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.)
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.javascript

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

--- Synchronet 3.20a-Linux NewsLink 1.114