W3C

- DRAFT -

Accessibility Guidelines Working Group Teleconference

13 Nov 2017

Attendees

Present
(no, one), Joshue108, alastairc, MikeGower, Laura, JF, Makoto, SteveRepsher, Glenda, Mike_Pluke, david-macdonald
Regrets
Detlev
Chair
AWK
Scribe
alastairc

Contents


<AWK> +AWK

<AWK> +Jasonjgw

trackbot, start meeting

<trackbot> Meeting: Accessibility Guidelines Working Group Teleconference

<trackbot> Date: 13 November 2017

Adapting Text

<AWK> https://www.w3.org/WAI/GL/wiki/Comment_Summary_1-4-13

<scribe> Scribenick: Joshue108

AWK: We have a comment summary.

<AWK> If the technologies being used allow the user agent to adapt style properties of text, then no loss of essential content or functionality occurs by adapting all of the following: Line height (line spacing) to at least 1.5 times the font size; Spacing underneath paragraphs to at least 2 times the font size; Letter spacing (tracking) to at least 0.12 times the font size; Word spacing to at least 0.16 times the font size.

AWK: Please have a look so e'one understands what it says

<laura> Current SC text in draft: https://www.w3.org/WAI/GL/wiki/Comment_Summary_1-4-13#SC_Text

AWK: This is AA.

<AWK> https://github.com/w3c/wcag21/issues?utf8=✓&q=is%3Aissue%20is%3Aopen%20label%3A~comment-adapting-text%20

LC: there are a lot

AWK: Laura has been working thru these.
... Laura do you want to walk thru?

<laura> Issue 551: restrict to blocks of text?

LC: Sure.

<walk thru comments>

<and proposed response>

<laura> Proposed: The Working Group will be going through the implementation process and demonstrating the implementability of all the new SCs. If you know of examples in the wild of text in UI - (e.g. menus, etc) where it would not be possible to meet the SC, please add them to this issue.

AWK: So that relies on implementation results?

LC: yes.

AWK: Is that a reasonable response to 551.

MG: Doesn't address the question.

LC: Ok, I can add the next one into this one.
... 496 is going to be too hard to test for example.

AWK: Does that address?

MG: Yes.

JW: We should expect some pages are going to fail.

<david-macdonald> is there a meeting now?

JW: Just because some are not going to pass thats not an argument against the proposal.

<Zakim> gowerm, you wanted to say that some SC are designed to not fail where freaky stuff isn't being done

<david-macdonald> Is there a link to the WebEx info

MG: Some SCs are written to ensure weird things are not being done, such as a user ability to override CSS.

<alastairc> NB: I was pushing for smaller values because I assumed it would be hard. Having done the testing, only a few bits of a few sites failed, and they appeared easy to fix. So I ended up supporting the values. However, people coming new might assume it is harder than it is.

MG: We want to limit though to attempts to do weird stuff.
... We whould identify that.

AWK: I'm not sure.

LC: Next is 418..

LC <reads out 418>

LC: Do people agree with that to change the name?

JOC: We'd need a CFC for that.

<david-macdonald> @awk, you mean with a phone, not WebEx

AWK: There are changes that will need that anyway.

JOC: Its not as snappy but it is more explicit.

AWK: I like Text Spacing.

AC: If it was extended in future to cover colour and font family?

<JakeAbma> +1 Text Spacing

AC: Then there would have to be an SC in 2.2 or 3..
... I like Text Spacing..

<david-macdonald> SOrry, confused... what number do we dial... webex numbers don't work

AWK: We may have to do something about Adapting...
... Something that says mechanism is avail etc.
... So you are not loosing content etc by making the adaptation?
... But you could meet this with a scanned doc.

JOC: But it has to be adaptable.

<david-macdonald> Does some have the meeting mumber, all of the meeting request emails I see in the mailing list don't work. UUURGH!

JW: What if someone wants to reduce it?

AC: It does need to be the ability to override..
... We are taking about font family also.. so these values are proxies

<david-macdonald> ok thanks

AC: So it is more about the override capacity than the value itself.
... There are certain things needed here.
... how can you test if the user chooses a larger font family etc?
... There are reasonable values to pick based on the normal distribution of font values.

JOC: I just see the printed doc suggestion as a straw man..

<alastairc> Those documents are scoped out by the first sentence

AWK: But if you have a doc which meets these criteria but you cant change it. Does it pass?
... If the technology allows it to change..
... If qualities are met before the script is run...
... And it meets it,does it pass?

AC: Yes.

LC: Yes.

<laura> Results of Bookmarklet Tests for Issue 78: https://www.w3.org/WAI/GL/wiki/Results_of_Bookmarklet_Tests_for_Issue_78

<alastairc> override could be used instead of 'adapting'

<AWK> 1.4.8 says "For the visual presentation of blocks of text, a mechanism is available to achieve the following:"

LC: We used override first

AWK: You will have the same problem

JOC: It sounds like this is a set of typographical requirements depending on various resolutions.

AC: People may think you may need an onscreen widget.

<gowerm> In discussion on the response to Issue 469, I made the point that the feasibility of some SCs is shown by the absence (or rarity) of issues against existing websites. That is not necessarily the case when testing for other SCs. Is this something worth capturing somewhere?

AWK: Mech available is used lots of places.
... What do others think?
... Do others interpret it like this?

LC: Oh yeah, from the beginning

DMacD: There is an onus on the dev to have a mechanism or know that the browser can make some adaptation.

content can either already be or is adaptable...

+1 tp remove flexible

<alastairc> happy with 'text spacing' without flexible.

<gowerm> Josh: "If content is already or can be adapted to" would satisfy the SC

<AWK> Josh: What about "content already meets or can be adapted to..."?

MG: We discussed this idea of going lower
... It seemed like meeting these criteria it ment you were authoring properly.

AWK: Like the reflow one...
... Requiring reflow by not specifying zoom level there may be issues.
... If you have a scanned doc you may pass this, but could fail others.

JOC: RIght

MG: This SC is to ensure text can be adapted.
... Those specs are there to create a testable SC>

AWK: The SC if not testable thats a disconnect.

MG: They were added to make sure it was testable.. but the argument is changing to see these specs as the goal.

AWK: People will look at what it is testing for..
... We may need to work on the language..

<laura> This SC does not dictate that authors must set all their content to the specified metrics. Rather, it specifies that an author's content has the ability to be set to those metrics without the loss of content or functionality. The author requirement is to not to interfere with a user's ability to override the author settings.

AC: I agree with what Mike was saying..
... We have a bar, if the site meets that bar and text is kept within these parameters then good.
... Without things breaking..

AWK: But the conformance claim is based on what the testers are using..
... Its not a requirement to change the font size..

LC: Its already considered..

AWK: Ok.

<AWK> For the visual presentation of text, a mechanism is available to achieve the following:

LC: Do you have a suggestion for text?

AWK: Yes, taking from 1.4.8 would be better.

<jasonjgw> +1 to Andrew's proposal.

AC: And I would avoid a mech is available..

<gowerm> +1 to avoiding "a mechanism is available"

LC: We spent a long time trying to convince people that they dont need to create a widget.

+1 dont want mech available either..

DMacD: We can provide a note..

<alastairc> -10 to "mechanism is available", much better to scope to "If the technologies being used allow the user agent to adapt style properties of text"

<AWK> For the visual presentation of text, a mechanism is available to achieve the following without loss of essential content or functionality:

DMacD: a mech is available.. etc

AWK: Lets go thru comments..

<steverep> What issue is being discussed?

AWK: 418..
... 409..

LC: Steve is on that .. want to talk with him.,

SR: I wasnt a fan of this..

<laura> https://github.com/w3c/wcag21/issues/409

SR: IMO the SC is clear, that the UA is doing the adapting..

LC: There was a response to your suggestion..

SR: Yeah, we could add a subject to the clause, when the UA adapts..
... That should clear it up.. I can write something up.
... We need to make clear that adapting is not the same as adatpable guidelines..

AWK: Would like to see the text..

LC: We are changing it to Text Spacing..

SR: Ok..

<alastairc> scribe: alastairc

<gowerm> Success Criterion 1.4.13 Text Spacing

<gowerm> If the technologies being used allow the user agent to change style properties of text, then no loss of essential content or functionality occurs by changing all of the following:

<AWK> If the technologies being used allow the user agent to change text style properties, the following can be achieved with no loss of essential content or functionality:

AWK: removes the 'by changing'

SR: Clearer about the user-agent doing the switching?

AWK: Prefer the second as it matches previous SC.

<gowerm> +1 to AWK's wording

David: Might some people be confused by lack of style-sheet user-agent differentiation?

<steverep> If the technologies being used allow the user agent to adapt style properties of text, then no loss of essential content or functionality occurs when the user agent adapts all of the following:

Laura: It's in the understanding doc.

AWK: Response for 408?

<laura> https://github.com/w3c/wcag21/issues/409#issuecomment-334674695

Laura: Not sure, she's brought in other issues, can't tell what the answer would be.

AWK: The change of text should negate the issues.

<laura> No. not yet.

AWK: The version I suggested doesn't specify as much, more flexible/open.

david: if someone doesn't do their stylesheet properly (e.g. missing !imprtant;), then it isn't the authors issue.

SR: Not sure this is the same SC, could be confusing.

<Zakim> gowerm, you wanted to say that the purpose was to ensure they could be adapted. The specs are to make it testable

<steverep> If the technologies being used allow the user agent to adapt style properties of text, then no loss of essential content or functionality occurs when the user agent adapts all of the following:

<AWK> We have updated the SC language and it no longer uses the definition for "adapt", so the issue is resolved.

<Zakim> steverep, you wanted to ask if we think it is still clear that ONLY those properties are changed?

SR: If the author writes a mechanism, that's getting away from what the SC language was intended to achieve.

AWK: If those 4 things don't result in loss of content/functionality, then we know the author has to pay attention to containers etc. Other ways you could do that.

David: You could provide one button that changes the text, which meets it, is that good?

AC: It could work that way, and then the user could override things to their own preferences. it isn't harmful.

<Zakim> gowerm, you wanted to say I'd like to see something like this at the start of the Understanding document. "The intent of this SC is to ensure that authors create pages where text

<laura> Undersanding doc: https://rawgit.com/w3c/wcag21/adapting-text/understanding/21/adapting-text.html

MG: People can do really stupid things for any SC, we can't prevent everything.

<gowerm> https://www.w3.org/WAI/GL/wiki/Comment_Summary_1-4-13#Issue_418:_needs_name_change_or_to_be_in_different_GL.3F

Laura: (reads issue 438)

AWK: Do these count as 'technologies'?

<AWK> https://www.w3.org/WAI/GL/wiki/Comment_Summary_1-4-13

AWK: Suggest 'text in images and video is not expected to adapt'.

<AWK> Text presented in video or as images of text are not expected to adapt

MG: Could link to definition of open captions?

<david-macdonald> If the technologies being used allow the user agent to change text style properties, the following can be achieved <add>, by changing only these properties,</add> with no loss of essential content or functionality:

<steverep> Text that is not affected by style properties, such as images of text or open captions, are not expected to adapt.

<AWK> In Caption definition: Open Captions are any captions that cannot be turned off. For example, if the captions are visual equivalent images of text embedded in video.

AWK: note the definition of captions includes what open captions are.

Laura: Gregg's comment 347 is to use open captions.

John: Concern isn't that they are open, but some 'open captions' can be done from a separate file.

Laura: Add to the note?

<Glenda> I recommend covering in Understanding

JF: Two ways of achieving it: burn it in, or the player can force them on.

AWK: Can we say 'burned in captions'?

JF: Only when the captions are part of the video frames that we mean it.

<JF> Open captions that are embedded directly in the encoded video frames

<AWK> Examples of text that are typically not affected by style properties include images of text and text within video, which are not expected to adapt.

AWK: In the understanding we should clarify the difference.

+1 to the simplest version, 'within video'

<Zakim> gowerm, you wanted to say most people would think that open captions are burnt in. By saying 'typical' we are covering it.

JF: Let's keep it simple, and keep and eye on the understanding doc.

MG: The wording now is typical, and links through to definition.

The legal bit would be the start of the SC "If the technologies being used allow the user agent to change text style properties..."

steverep: I wrote it initially to get around these examples.

<Glenda> +1 for removing the note

<steverep> Text that cannot be affected by style properties are not expected to adapt. (no examples - leave for understanding)

<JF> +0

<Wilco> +0

no objection, I think it's been over-taken by changes to the SC text.

<laura> Proposed Response: Thank you for your comment. The SC note has been remove. We will be addressing Captions and images of text in the understanding document.

<laura> https://www.w3.org/WAI/GL/wiki/Comment_Summary_1-4-13#Issue_390:_i18n_concerns

<laura> Issue 390: i18n concerns

AWK: I think Richard's comment is around tracking as emphasis, and we might loose information.

Laura: (Reads proposed response)

<AWK> Alastair: we need to make sure to say that the research was primarily done in english

<AWK> ... bottom line it is a user-defined thing

MG: Would be good to invite examples or further comments.

Issue 388

<gowerm> We should cover internationalization in the Understanding document, if it's not there already.

AWK: all we can do is set a baseline for western languages, that might not be as useful in other languages.

<Detlev> Had some last minute urgent stuff landing on my desk, sorry!

<david-macdonald> If the technologies being used allow the user agent to change text style properties, then no loss of essential content or functionality occurs by changing all of the following:

David: Looking at whether new language is ok, think the new text leaves a hole. (Text above) plugs the hole.

AWK: Come back to it after 349
... It is reasonably tech-independant, if the tech allows it, the author should to. don't think it should be restricted to HTML/CSS.

<Detlev> David: is there any question (related to German) that I should answer

<AWK> @detlev it would be good to hear your thoughts on the german reference in issue 388

<AWK> (via email is fine

<AWK> )

<Detlev> will respond on list

I think it was this one: https://github.com/w3c/wcag21/issues/390 for detlev?

<david-macdonald> If the technologies being used allow the user agent to change text style properties, the following can be achieved with no loss of essential content or functionality: If the technologies being used allow the user agent to change text style properties, then no loss of essential content or functionality occurs by changing all of the following:

<david-macdonald> If the technologies being used allow the user agent to change text style properties, the following can be achieved <add>, by changing only these properties,</add> with no loss of essential content or functionality:

David: that's not good, as without specifying the method (override) it puts much more on the user to change, e.g. layout/padding type things.

<steverep> If the technologies being used allow the user agent to change style properties of text, then no loss of essential content or functionality occurs when the user agent changes only the following set of properties:

<Detlev> You see tracking in German as a method of emphasis only rarely

<laura> Thanks all.

<AWK> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/11/13 17:05:26 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/ beginning?/ beginning/
Succeeded: s/for other SCs/when testing for other SCs/
Default Present: AWK, Jasonjgw, Joshue108, alastairc, MikeGower, Laura, JF, Makoto, SteveRepsher, Glenda, Mike_Pluke, david-macdonald
Present: (no one) Joshue108 alastairc MikeGower Laura JF Makoto SteveRepsher Glenda Mike_Pluke david-macdonald
Regrets: Detlev
Found ScribeNick: Joshue108
Found Scribe: alastairc
Inferring ScribeNick: alastairc
ScribeNicks: Joshue108, alastairc
Found Date: 13 Nov 2017
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]